I am a programmer - <AUTHOR> http://www.jacquesmattheij.com/I+am+a+programmer <comment><USER4> The problem I have with Patrick's essay ("you are not a programmer") is that it addresses a situation that hardly any developer ever finds himself in. If I go to interview for an engineer position, it matters exactly not one bit that I try to pass myself off as a solutions architect or a business problem solver, except for possibly some awkward glances back and forth. All they want to know is how long I've been coding Blub, which frameworks I use and why did I quit my last job? If all is well I will start on Monday with checking out the SVN repo and start getting to know the code. Should I start trying to analyze the company's business processes that would be an awkward conversation indeed with the department manager.

I think that is the reality most developers find themselves in. I doubt it's been any different for Patrick until the consultancy spinoffs he can now pull on account of his personal brand.

So I kind of agree with Jacques here, with the exception that I don't call myself a programmer in conversation with people outside the field, since it sounds a bit like "punch card operator". That doesn't change the fact that I really am a programmer first and foremost.

<comment><USER5> _a situation that hardly any developer ever finds himself in_

"To a worm in horseradish, the world is horseradish."

(Sorry, have actual work to do today, so I'm going to reply mainly in epigrams where I can. ;)

 _pass myself off as... a business problem solver_

Nobody is suggesting that. You don't _pretend_ to solve problems for your business. At least, the business doesn't think so. They pay you. They don't pay people just for fun. _They_ obviously think you're solving some kind of problem, _right now_.

Even within the seventh layer of a nine-layer bureaucracy, your peers have a problem that they are paying you to solve. Figure out what it is and learn to talk about that.

This needn't be self-aggrandizement, either. "I am one of ten interchangeable members of the QA team that keeps our customers happily renewing their subscriptions by finding bugs before they even see them" is fine. You needn't claim to walk on water all by yourself. People like loyal team players.

If you find that you can't talk about your problem without feeling dirty: That's a data point. If part of the job is "follow orders without thinking like a good little interchangeable part", that's a data point. If you discover that the problem you're solving is "win our division's internal war against the Other Division, customers be damned", you have a data point. If you come to the conclusion that you are in fact paid to _cause_ problems, but the company can't figure that out because the intervening tangle of bureaucracy is disguising the fact, that's a data point. Try to keep doing your job well, but as the data points accumulate, and depending on your personality, you may find that other jobs are calling.

<comment><USER6> _Nobody is suggesting that. You don't pretend to solve problems for your business. At least, the business doesn't think so. They pay you. They don't pay people just for fun. They obviously think you're solving some kind of problem, right now._

Well, often the 'problem' as such is "lack of programmers". The business value/problem has already defined by other people, and a solution decided on, and you need to code it. At least, that's the position I'd been in in the past. I might have come up with a clever algorithm that solved a particular internal problem on that project, but the overarching project being worked on wasn't really solving the original business problem that was presented. However, as lowly-coder-#17, no one really cares what your views are - <USER2> _problem_ you're solving is manpower to implement someone else's vision, right or wrong.

</comment></comment></comment><comment><USER7> "We're middle-men (and women), glorified translators"

By that rationale, teachers are glorified dictionaries, accountants are glorified calculators, and lawyers are glorified secretaries.

"Programmers don't 'unemploy' people"

Bullshit. If I build an automated fraud detection system for a bank and they lay off 50 people in charge of fraud detection after it goes live, I most certainly made their jobs redundant. If I build a more efficient control system for an automobile plant, and they lay off operators as soon as it goes live, I've certainly made their jobs redundant. Efficiency kills jobs by definition. You only create more jobs when you start in a new area, or as a competitor. And even then it's only temporary until efficiencies kill those jobs as well.

"As a ground rule, as long as you are calling other peoples modules you're not yet programming"

Then, as a ground rule, as long as you're drawing triangles, arches, and straight lines, or using a CAD program, you're not yet architecting. As long as you're using 2x4s or windows made of glass you didn't blow yourself to build a house, you're not yet building.

Why does everything have to be built fron scratch in an intellectual vacuum in order to be "real"? Isn't the whole point to stand on the shoulders of the giants who came before?

"Whether you use the word programmer to describe yourself or not has very little to do with what your bank statement tells you at the end of every month."

Actually, it has a LOT to do with what your bank statement tells you at the end of the month. The world runs on respect. And respect comes from other people. Give yourself a title that engenders respect and you'll find yourself able to negotiate FAR better deals for yourself than you would with a less respectable "I'm-just-a-replaceable-cog" title.

"And in such places (and unfortunately also in quite a few smaller ones) the market value of what a person doing your work is charging is what will determine your pay"

No, the market value of a person with your TITLE is what will determine your pay, unless you're known to be a pushover who accepts promotions without pay increases. And if such a 'promotion' happens, you gladly accept it anyway, and then leave 6 months later with your new title to leverage a better salary.

<comment><USER8> _Efficiency kills jobs by definition._

Yes, efficiency kills (old, existing) jobs, but that gives new leverage to expand production beyond what it was before.

That's why the wheel, the industrial revolution, etc. have all increased the well-being of the world, not decreased it.

It's called progress.

<comment><USER7> "Yes, efficiency kills (old, existing) jobs, but that gives new leverage to expand production beyond what it was before."

This is moving beyond the original point, but since we're here...

When increased efficiency kills jobs, the now jobless need to move onto some other form of employment. We saw this happen in migrations from farming to factory jobs, and now from factory jobs to service jobs. That area is safe for now since it's still hard to increase efficiency in services such as grooming, food preparation, entertainment, driving, and yard trimmers, compared with industrial production.

So there's still a certain stability in the current system that is not disrupted by emerging efficiencies, but that won't last forever. Eventually, even the services industry will become efficient, at which point the trend of jobs becoming scarce will accelerate to the point where it becomes impossible to employ everyone, unless you start inventing "busy work" jobs or change the work-to-live dynamic.

I'm neither calling it good nor bad; I'm just highlighting the need to come to terms with it, because it will come regardless of our preparation.

<comment><USER8> _I'm neither calling it good nor bad_

That's the real issue at stake. You should be calling it good, because it's progress.

It's somewhat conceivable that there can be times in future human history where there are large chunks of people who aren't capable of doing any productive work, but they probably won't be lasting. [1]

And for everyone who can find productive work, more efficiency in the global economy enables more production, thus more progress, and is therefore a plus.

[1] Partially because if we do things right, population will gracefully degrade in times when fewer jobs are available. (I'm not advocating more social controls to achieve this; providing additional money per-child to those on welfare, for example, goes strongly against this.)

<comment><USER7> I'm not calling it good because I just don't see the graceful transition occurring. If anything, I see massive upheaval because almost everyone will deny the reality around them until it becomes impossible to do so.

In a perfect world, I'd agree with you. However, we don't live in a perfect world.

<comment><USER8> Do you have any ideas on how to avoid or cope with this massive upheaval?

<comment><USER9> I agree with you javert, that increased efficiency and productivity are good things. But I do so for a fairly uncommon reason: I think that we have very little idea of the capacity of one person.

Our economy is still marked by massive disruption: technological innovation isn't just limited to services. Process engineering, chemical engineering, astronomy, physics, linguistics, archeology, ... they're all experiencing disruption at an increasing pace. They all increase GDP.

To me, this is an indication that as we provide people with powerful tools, their minds expand to use those tools. The exponential feedback may become much more smooth (less "disruptive") but I think we're a long way from a local maximum.

The current economy still "feels" like an idling 2-stroke leaf blower to me. It sputters and races because its carburetor and ignition are, well, inefficient.

What would it take to get a jet engine-like economy?

<comment><USER8> I like what you're saying.

However, you're not answering your comment's grandparent: how to avoid, cope with, or assume away the concern that a super-high-tech economy will leave unemployed people who aren't intellectually sophisticated enough to participate.

<comment><USER10> _or assume away the concern that a super-high-tech economy will leave unemployed people who aren't intellectually sophisticated enough to participate._

Is changing your intellectual sophistication hard? I mean, I learn programming by basically bashing my fingers against the keyboard. The concepts aren't difficult to learn, but it require tons of practice to become competent.

<comment><USER8> Well, that's one (potentially valid) way to explain away the concern.

(I should have said "explain away" instead of "assume away.")

<comment><USER11> I personally work a lot with 3d animation. We use plugins and pre-made elements to create our animations. Because we are using 3rd party tools to create our final product, does this make us "middle-men (and women), glorified translators", Or is it only real if we where to make our tools form scratch.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> The problem I had with Patrick's essay is how derogatory it is to what we do.

I am a programmer because it's what I like to do. People pay me money to do it. And when I go home I read about it, talk to others about it, and I practice, practice, practice. I think about how I can write better software, reduce the amount of bugs, test better designs, and improve my productivity. I think about programming all of the time.

And like Jacques, I'm not afraid to tell others that I'm a programmer. I think most people understand what that is by now. I write programs for computers. If I say "Systems Analyst," or "Solution Architect," they will probably look at me funny and ask what that means. In an interview... it will probably be passed over without a second thought. So I call myself a programmer.

And I call myself a programmer with a bit of pride. It isn't an easy profession and involves far more than typing in a bunch of things that make computers do stuff. Experienced employers will have realized this before sitting some one such as myself down in an interview. They want someone with enthusiasm for the craft, the experience building many different systems, and the ability to learn. There was a time when I would have accepted any programming job. However there comes a point where talking to yet another company who just wants to replace a cog in their machine becomes a waste of your time. It is hard to be good at this job and experience and ability has a cost associated with them.

So yes, I am a programmer. Thanks Jacques for writing this.

<comment><USER13> The point of Patrick's essay isn't "Programming is lame" or "you shouldn't be proud of your programming accomplishments." How did anyone take that away?

      > It isn't an easy profession and involves far more than typing in a bunch of things that make computers do stuff.

This is true. Nobody said that wasn't the case.

      > I'm not afraid to tell others that I'm a programmer. I
      > think most people understand what that is by now. I write
      > programs for computers.

Look, I love writing code. I <3 proper testing. I take pride in my work and try to provide the best code I can possibly write.

That said, coding is what we do to achieve _something._ Maybe you're trying to make it easier for your support team to track tickets, or helping your client's customers save the most money.

I get that you're proud of your development skills, but at some point your software has to solve a business need, and you need to understand what the need is and how your software is solving it. All the unit tests and properly factored code won't mean anything if you don't. You'll write unnecessary features, or miss writing necessary ones.

Patrick's point as far as I understood it was that _we all understand this_ but we're not billing ourselves that way. If I'm in an interview, or discussing my work with a non-technical associate, I emphasize my ability to understand business needs and write software to meet them. When I talk to technical folks, I emphasize that I unit- and integration-test all of my code and that I understand why DRY code is great.

      > The problem I had with Patrick's essay is how derogatory
      > it is to what we do.

On the contrary, I think it celebrated what we do. Not the technical aspects -- squeezing performance out of underpowered machines or designing remarkably simple architectures -- but the _final outcomes_. This app saved us millions per year. These new dashboard reports helped us earn 20% than expected this quarter.

<comment><USER12> _"Programmer" sounds like "anomalously high-cost peon who types some mumbo- jumbo into some other mumbo-jumbo." If you call yourself a programmer, someone is already working on a way to get you fired._

That sounds derogatory to me. His opinion is that business types could care less about what you do. You're not a _programmer_ but an exploitable resource. Since when is being a crafts-person and being proud of your work and what you do bad?

 _I get that you're proud of your development skills, but at some point your software has to solve a business need, and you need to understand what the need is and how your software is solving it._

I'm in the business of producing good software. How does calling myself a programmer have anything to do with what you just said?

It's a matter of perception. Patrick thinks people think programmers are clueless navel-gazing cogs who don't have a grip on reality. Of course nothing could be further from the truth -- a good programmer is probably more in touch with the needs of the business than the ignorant stakeholder who thinks programmers just type in a bunch of stuff. I think this perception is a disservice to both programmers and business people alike. I do not doubt that there are people in the world who perceive programmers in the way Patrick describes... but I wouldn't work for them for anything less than a big six- figure salary and very gracious vacation allowance. I think most people understand that programmers make software and software solves problems for businesses and consumers which makes money. Therefore programmers must be pretty important.

So yes, I still call myself a programmer. If I catch wind that the person interviewing me views me as a 'peon' I walk. If that's what they're looking for it's their loss. They can figure it out later I'm sure and might come back to me when their spending 80% of their time and budget fixing the errors their "peon" introduced into their software.

Good programmers are hard to find. I don't see anything wrong with calling myself a programmer.

<comment><USER13>
      > Since when is being a crafts-person and being proud of
      > your work and what you do bad?

Nobody said it was. Not the original article, not me, not anyone.

      > I'm in the business of producing good software.

I don't know, maybe you are.

Right now, I'm in the healthcare business. My main client is a medicare company and they want people to sign up for their plans and fill prescriptions, preferably for the cheaper generics that save them money but still provide therapy required.

I meet those goals by writing well-architected software with solid test coverage. I make my job easier on myself by making my deployment a single- click affair. That's part of being a good developer, but that's not what I'm paid for. I'm paid to meet business goals. We got this client by writing software that meets those goals better than their original vendor. If someone comes along who writes poorly-architected messes _but that achieve those goals better_ my client will leave me for them. I will be disgusted as a programmer that this happened, but it only makes sense.

      > I don't see anything wrong with calling myself a programmer.

That's fine. Call yourself whatever you want. But -- _and this is the entire point of Patrick's article!_ \-- assuming that people understand the value of a good programmer is a _mistake_. Rather than dismissing folks who don't instantly comprehend your brilliance, maybe you might try explaining to them the value that you provide in terms they can understand.

<comment><USER12> _If someone comes along who writes poorly-architected messes but that achieve those goals better my client will leave me for them. I will be disgusted as a programmer that this happened, but it only makes sense._

I understand what you're trying to say, but I disagree that people perceive "programmers" as highly-paid peons. If they did, why would you want to work for them? There are companies who are desperate for good programmers and recognize that good programmers are hard to come by. Negotiating with them is much less adversarial, I assure you.

I don't disagree with a lot of what you're saying. I think we can both agree that a good programmer understands their role in the business and should view their practice holistically as a part of a much bigger entity. However, I don't think that people universally see programmers as overly-paid gurus or what-have-you. Assuming they want skilled programmers to work for them, why would they look for replaceable cogs and peons?

The true cost of hiring those kinds of programmers will not be apparent until 5 years down the road when you're spending 80% of your budget and time fixing bugs and putting out fires from pissed off client who cannot believe you would ship them such a shoddy product.

Again.. maybe there are people in the world who still do not know what a programmer does or the value of hiring good programmers. I would argue that they're probably in the minority or hiring for a position that doesn't require a lot of skill. In that case perhaps Patrick is right -- but again, why would you want to work for them unless you're desperate to fill in your H1B requirements or you're straight out of school and have no experience. A good programmer can do a lot better in my experience.

</comment></comment></comment></comment></comment><comment><USER14> Patrick's essay had nothing to do with titles. It was about describing what you do in terms of the benefit you provide to your customers/employers rather than in terms of the skills or tools you use to provide that benefit.

I could tell people I can program Excel interop in .NET, or I could tell them I saved my company dozens of hours a week by automating an administrative process. To non-programmers, only one of these descriptions sounds interesting. A programmer can hear "Excel interop in .NET" and infer automating administrative tasks. A business person, generally, cannot.

Patrick's essay was about being explicit about the value you provide, not about picking a fancier name for yourself.

<comment><USER15> I feel that is the wrong way to approach things. Your _job_ as a programmer was to provide that deliverable as set out by your position. You programmed it and it went along. The outcome of that deliverable was the improvement but your job was to construct it.

I don't pretend that my past jobs were "automating IPTV interface interactions" or "enabling alternative business transaction venues"... I was programming what was needed. Its a white lie the industry has gotten comfortable with and I think we'd be better off if this path was never went down in the first place. People prettying up their titles have essentially "robbed" honest ones ("I'm a f*king programmer") from being treated in the same regard.

<comment><USER5> It is hard for those of us who know how to tinker to appreciate that there really _are_ folks who don't tinker.

You assign them to pull the levers, and they pull the levers. If the machine they're running is manifestly inefficient, they don't notice, or they pretend not to notice.

(Or – if they're good – they adapt _themselves_ , adopting a complex series of difficult physical and mental moves to compensate for the machine's brokenness. Sometimes those physical moves are such that, after four years on the job, they'll be in the hospital. But they do them anyway, because, hey, making the inefficient machine work is their job.)

If the machine next to theirs is broken in a way such that it messes up half of the work coming out of _their_ machine, they just keep going -- hey, it's their job to run _this_ machine, not _that_ machine. If the machine they're running breaks down, they call for help and then sit there unmoving until help arrives. ("I didn't want to break anything.")

You tell them to RTFM, and they do, all of it, and then they come back to you: "I read the whole manual; now what do you want me to do?"

They may have even _memorized_ the manual. It's not that these people aren't smart and eager to please. Indeed – and this is the thing I have trouble getting my head around – sometimes, within their area of expertise, they may know how to _tinker like mad_ , they know the freaking _serial numbers_ of every part of their machine and which ones can substitute for each other in an emergency. And yet, beyond their area, there's this strange paralysis. You hand them the duct tape and gesture encouragingly at a neighboring machine and... nothing happens.

If you give such a person a room full of miscellaneous broken things and ask them to fix everything they will proceed at a rate of (1 + epsilon) hour of progress per hour _you_ spend telling them what to do. On the flip side, if you give them a room full of ten thousand widgets to finagle and they have a certification in Widget Finagling, those widgets will get finagled. They might even work overtime to please you. And when the widgets are done they'll go home, _even if the rest of the factory is on fire_ , because there's nothing left for them to do.

When hiring someone to solve our problems we desperately need to know whether or not we're getting a hacker, or a technician. Both have their roles, but they can't substitute for each other.

<comment><USER16> This is true. I know someone who has bluntly me told me they don't want to think at their job.

</comment></comment></comment></comment><comment><USER17> Yes, me too, I'm a programmer. That's how I think of myself, regardless of what infinitely varied tasks I may do. And me too, that's what I blurt out when people ask me what I do.

In more formal contexts, like resumes and job apps, I call myself a software developer, because that's a more encompassing description of what I do. Software development is not just programming, even if that's the most obvious and the most fun part.

My employers call me whatever they want to call me. That's been technical staff member, programmer, software engineer, etc.

I never voluntarily call myself a software engineer. I've never worked under the supervision of a PE who was legally responsible for my work, and I've never been on a track working toward my PE. Very few software developers work in that environment.

I don't mind the informalization of the term software engineer, but I don't use it because I've never, ever worked in an environment where programming or software development was practiced as an engineering discipline using national or international standards of practice or product. Software development where I've been, and where most people are, is much more an individual art than a community science. So I don't want to give the impression that what I'm doing is in any way a legal, formal engineering practice.

<comment><USER18> > I never voluntarily call myself a software engineer

I actually had my company change my official job title at one point in my career to "Software Developer". I have an undergraduate degree in engineering (partially because I wanted to rebel against my parent's wishes for me to do CS). Software cannot be engineered like a bridge. Structural engineering is very narrowly scoped. You have a design load, comprised of live loads like wind and moving cars and static loads from the weight of the structure itself. There are entire "cookbooks" of formulas used to compute the theoretical, accepted thickness of the support beams and bolts. There is standardized everything, from the project management terminology to the thread count on the bolts. After graduating, if you gain four years (in some states, less) of practical engineering experience, you can take the Professional Engineer (PE) exam. In some cases, to prove your experience, you need to submit three inches thick of paper calculations you have done while working. The PE exam is rigorous and graded on a curve. But once you pass, you get the pride and responsibility of having a seal that you can use to emboss blueprints. That says you take responsibility for the work. Software development is not engineering, and I have strong philosophical discussions with those programmers who insist on that term.

Software development is creative problem solving. You do not have much creativity in structural engineering.

<comment> T-hawk > Software cannot be engineered like a bridge.

It can be, as in the world of formal proofs and languages like Ada which facilitate them. It just typically isn't, as such formal procedures are far more costly and slower than than just dealing with bugs as they happen. For critical software systems like say avionics where a failure case is extremely costly (in both money and casualties), there do exist certification programs and rigorous methods as you describe for structural engineering.

It could be argued that avionics behaves more as engineering than as programming. Then we have a self-fulfilling definition: if we define fields with rigorous procedures as engineering, and fields without as software development, then of course software development doesn't have formalized methodology.

You're also comparing the largest scope of structural engineering - a massive bridge - with the entire spectrum of software. Engineering does happen on a smaller informalized scale too, like a homeowner building a shed or a Boy Scout troop building a rope obstacle course. That's still engineering, applying skills in carpentry or knot-tying to build something.

</comment></comment></comment><comment><USER19> I am a programmer, but I am not a programmer.

The problem is, 'programming' as such is the end of a process. That process begins with talking to a customer about his or her idea/business problem, and asking questions and (basically) doing consulting to help the customer understand what his or her problem really is. Once that's clear, I write a proposal that outlines how I would address that problem, all in strictly high- level layman-understandable language - no mockups, no screenshots, no technical language, nothing. Then, once we agree on that, I contact a designer to help out with the design of the app, and to think about new and novels ways to make the interface as simple as possible. We show it to the customer, refine it, and get an agreement on all that stuff. And then, finally, three months since that first meeting, I can start with the programming.

So yes, I'm a programmer - but only if an academic is a writer, if an architect is someone who draws, and if a manager is someone who talks to people.

<comment><USER20> > _And then, finally, three months since that first meeting, I can start with > the programming._

In my world (iOS), if it takes you three months to even start moving, you'll miss the market opportunities far too often. 3 months ago, iOS5 storyboarding and multitasking weren't even a concern and most developers were split between Xcode 3.x and 4.0!

<comment><USER21> And as a data point from a completely different industry, it can take me three months to get approval to fix a bug.

Apples, meet oranges.

</comment></comment></comment><comment><USER22> _Job security, job satisfaction, good pay. Pick any two._

This statement doesn't make much sense when you think about it. It seems to be a lazy riff off of:

 _"Fast, cheap, quality: Pick any two"_

Each of those characteristics are in competition with each other. Doing something fast often hurts quality and/or cheapness. Doing something cheaply may take longer and may harm quality.

Job security vs. job satisfaction don't really compete with each other. In fact, being more satisfied (i.e. happy) at your job may lead to better security indirectly, as a happy worker is a more productive, engaged, and charismatic worker.

Perhaps JMJ is trying to appeal to the commonly-held notion that fulfilling, satisfying jobs are ones that don't pay well - teaching, research, social work, etc. OK, it applies to certain sectors. But not across all sectors. A failure to recognize the inherent structural differences and opportunities between job fields (and public vs. private) hurts whatever rhetorical argument he's trying to make here.

<comment><USER23> I've heard this sentiment phrased much better:

"There are three things that mostly determine how well your life goes: what you're doing, who you're with, and where you are. If you can get two of the three right, you're ahead of 90% of the human race."

Sometimes there are tradeoffs between the three, sometimes not, but it's really, really hard to get all three to line up together.

<comment><USER22> Yes, and I'm sure that's what Jacques meant. Getting each of those qualities on their own can be difficult, but they are not in direct competition with each other. Nitpicky, maybe, but it's an important nuance.

In the limited context of tech jobs and entrepreneur, I don't think it's quite right to tell people that it's not possible to achieve all three. And it may even be counter-productive.

</comment></comment></comment><comment><USER15> The biggest quarrel I have with this whole debacle is how it all started out. A group of wise asses decided they should fancy their title up and now everyone has to "to stay relevant".

The fact is I _AM_ a Software Engineer. I have a degree in Applied Science and I have my Iron Ring. I am registered with my provincial Professional Body. Saying that, I am not just a "Programmer" (I do not mean to sound derogatory) but there is a difference in the fields that I think is getting blurred.

I turned down many jobs that wanted "programmers" because I am an "engineer" and don't want to fall behind in my primary field to take a job that is loosely related. I code at home in my own time releasing small projects only recently digging into bigger ventures that are potentially able to turn profit but that's beside the point. Where I am now is an engineer's job. I do programming yes, but my job requires more than an understanding of computer architecture and design pattern competency to succeed.

I feel like I'm sounding like an ass. I am much more humble I swear! The point is that Software Engg != Programmer we need to stop fooling ourselves and allow the segregation to occur so that programmers are properly recognized and respected for their work!

<comment><USER24> Frankly, I dispute the existence of a "Software Engineer."

The UK and parts of Canada may recognize and regulate people with this title, but I don't believe that the same rigor _can_ be applied to building software.

You would have to work with formally verified (and I mean that in the mathematical sense) hardware and software all the way up and down the stack (that would include the language and compiler you utilize). You would then have to formally verify your own software on the stack you are deploying to. Only then would you be approaching the rigor that other Engineering professions are held to.

<comment><USER25> I've worked on avionics flight management systems. We had reams of system requirements, multi-person code reviews for every line of code in the product, formal verification runs, system integration testing, field testing... The compilers used were qualified for our use. All libraries used were qualified. All operating system components used in the product were qualified. Internal tools that automated any part of the process were qualified.

I'm not sure what your criteria is for "mathematical" verification, but I see this sort of work as software engineering.

<comment><USER24> The aerospace and medical fields have done quite a bit to increase the rigor in building software, however there doesn't seem to be any push from them to codify their processes and establish some sort of push for the industry as a whole. The establishment of a true Software Engineering discipline would require some consensus on the use of formal methods in specification design, and then program verification.

The other hurdle is that you need the same rigor from your hardware designers. Just as structural engineers must rely on the rigor of steel manufacturers, we are held hostage by hardware manufacturers. Frankly the entire industry needs a wake up call.

As for formal verification, it is the mathematical proof (in the pure sense) that a program behaves exactly as speced -- the specification must also be formally verified for consistency. Currently this is only possible on relatively small programs, with the largest being several compiler back-ends being verified.

Here's a paper on what it took to formally verify the seL4 micro-kernel: <http://www.sigops.org/sosp/sosp09/papers/klein-sosp09.pdf>

<comment><USER25> Codify their processes?

<http://en.wikipedia.org/wiki/DO-178B>

On the avionics software I worked on, we (another group of people) designed and manufactured the hardware. I'm not as familiar with the process there, but I have no reason to believe that it wasn't done with similar rigor. [See <http://en.wikipedia.org/wiki/DO-254>]

I understand mathematical proof, but I wasn't sure that was what you meant. I did not realize that physical engineering projects are mathematically proven to that extent?

<comment><USER24> I'm sorry, I wasn't very precise in my language, I meant the industries working together to generate a more generic process that isn't tied to a specific industry. This would be done with the intention of building a Professional Software Engineer program.

Anything relying on the physical world obviously cannot be mathematically verified, however the mathematical rigor is still there in the modelling and testing.

<comment><USER25> Ah, I think I follow then. Mathematical proof of very large software systems may presently be impractical; the verification procedures currently in place for avionics systems are pretty daunting as they stand.

I'm not sure what we would gain from an overall software engineering professional qualification. While I am quick to point to avionics development as (in my opinion) being true software engineering, I also acknowledge that a great deal of software is not built using any methods even remotely as rigorous. But then, it also probably doesn't need to be.

You put a lot more rigor into building a house for people than you do a house for dogs, and you put a lot more rigor into building a skyscraper office building than you do a house. And rightly so. Each needs to withstand different levels of pressure. I see no reason to apply rigorous engineering processes to iPhone games; it would be a waste of time and resources.

As it is, the industries that require rigorous software development have produced their own standards. I suppose if you could ascertain the similarities across industries and codify that into general software engineering practices, that could be a good thing, but you'd probably still need industry-specific regulations to make sure nothing was missed.

I dunno. Maybe if more software needed extensive rigor it would be more obvious what needs to be done across industries.

<comment><USER24> There are tons of industries that _should_ require it. The issue is that we focus in on the software that can directly kill us, rather than all the software that can indirectly do it. We instantly reason that all software we use to control things like cars or airplanes should be highly controlled, but what about financial software, phone systems, medical records software?

One of the sloppiest and haphazard programmers I ever worked with is now writing software for non-critical medical monitoring devices (external monitors like O2 sensors, and blood pressure monitors) and it scares the living daylights out of me. When I'm in a hospital room I look around to see if his company's hardware is in use. It might not kill me, but it could contribute to that end.

I'll come full circle around to my initial assertion that I don't know if we can even get to the point of a true Professional Software Engineer. Many of the tasks we deal with are highly abstract. How do we define an acceptable failure rate for a TCP stack? And even if we do, how do we take that into account for a monitoring application? There are many hard questions we have to tackle prior to our industry being taken seriously as a true engineering discipline.

What troubles me is that very few of the leaders in the software community even care about these questions.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> Although there is no mentioning of any references, I have a clue that it is a response to "Don't call yourself a programmer" (<http://news.ycombinator.com/item?id=3170766>)

<comment><USER27> I think that if jacquesm was living in Japan like patio11 (I also live in Japan), he wouldn't call himself a programmer either. Because a programmer in Japan is someone that takes a spec or a task, written by an engineer, and "translate" it into code. A programmer doesn't solve any problem, he implements another person solution, and that's it.

But at the end of the day it's not strictly about semantics, I think it's also about how you understand you work. When I don't introduce myself as an entrepreneur, I always introduce myself as a software engineer. Not out of elitism or anything like that, but because I think it carries more the fact that I am here to solve problems, and that programming is just one possible mean to this end.

<comment><USER28> I wonder what those specs written by engineers look like. How much details do they provide? Is the architecture of the project already specified? Algorithms and data structures already provided? If that's the case then wouldn't it be quicker for those engineers to directly type their specs in a high-level language? If that's not the case I think there are still a lot of problems for the programmer to solve.

</comment></comment></comment><comment><USER29> I would argue that this semantic debate over the meaning of "programmer" is getting a tad tired. The author description would be more aptly described, in my opinion, as an entrepreneur.

Conflict management, and the other business-focused tasks he mention are completely separate from the programming side in the corporate world. I worked at a company where the software developers spent 90% of their time writing code based on tasks, and nearly no time on these other facets described in the article.

Suffice to say, I think that more focus should be spent on what people are doing, and not what they're calling it. Which is sort of what the author was saying, in the end.

</comment><comment><USER30> Patrick's essay covered a lot of ground. It expanded on its title by explaining what companies value. The essay as a whole did not seem focused on job titles. The essay title did focus on job titles.

I see a wonderfully self-referential thing happening when people focus on the title of the essay. Maybe people do focus more on titles than they should -- both essay titles and job titles. Maybe job titles are as important as essay titles and email subject lines.

Patrick's essay was adaptibly engineered. If titles are what get through to people, the essay title will convey what's imprtant. Otherwise, the essay body will convey what's important.

</comment><comment><USER16> What this particular farcical drama boils down to is the tension between the creative and the business. It is identical in spirit to the musician's dilemma.

Usually it comes out to something like this, "Do we take pleasure in our art and pursue the art, or do we take pleasure in selling our art in pursuing that?"

It's painfully obvious that good businesses pay people to create a positive value proposition for them. Therefore, if you are running your career like a business, you need to be seeking to maximize your value proposition. Part of that is passing yourself off as a maximal value creator. That is one half of the essence of patio11's point.

A lot of the artists I've dealt with are content to seek their art and to work in badly paid jobs to maximize their pursuit of their art. As someone who can program computers, we can draw value from our art. We do not _need_ to hack at night and work as a barista during the day. That is the other half of the essence of patio11's point.

No one has to take patio11's advice, and their priorities may not align with his priorities.

But if you're maximizing wealth creation through being a programmer, you need to stop 'being a programmer/hacker/ninja/rock star/operator' and start 'being a person who creates wealth for other people via technology'.

</comment><comment><USER31> I've been re-reading the Gervais Principle series[0] recently, so I can't help but to construe both the original essay[1] and this response in terms of Sociopath, Clueless and Loser dynamics.

The original essay could also be called "A Loser's Guide To Careers" -- it's a realistic assessment of the options and opportunities offered to most engineers. It recognizes that most readers will be, in the grand scheme of things, on the short end of the stick and will have relatively little to bargain with. Accordingly, it dispenses cold, rational advice for how to best bargain with that limited leverage.

Both the Sociopath and the Loser are realists, it's only that the Loser has little meaningful leverage; he accepts this and so makes the best time-money bargain he can negotiate.

The Clueless, however, is clueless -- he would like to believe he is making a difference by keeping his head down, working hard and following the rules; instead, he is setup to be a mediocre middle manager at best, and a scapegoat at worst. And this essay could best be called "A Clueless Defense." That is not meant to slight any of Jacques technical achievements or prowess. Instead, I apply the term "clueless" here to mean that Jacques is being hopelessly naive. This essay is essentially a celebration of Jacques refusal to accept the situation in which he and other engineers find themselves: a world where those who hold the largest stakes (in any venture we choose to participate in) generally have no clue what value we provide and are incented to reduce our stakes.

(Yes, there are exceptions, even successful ones, and I think I work at one of those. But I don't blindly believe it, and I wouldn't bet my life or my family's future on it.)

I could write a lot more about my feelings on "I am a programmer,": I don't like it. I've already said that I find it naive and I don't want to cause unnecessary offense. Still, I commend Jacques for writing it at all and there's no reason to alienate him in disagreement, because it's an honest expression of his feelings. But I do want to say that, as a worldview, the idea of it being useful for understanding the trajectory of your career... well, I'm reminded of a line from the Futurama episode "Love and Rocket":

"Oh I would dearly love to believe that were true. So I do."

(And also -- the original essay has nothing to do with job titles.)

[0] [http://www.ribbonfarm.com/2009/10/07/the-gervais- principle-o...](http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or- the-office-according-to-the-office/) [1] [http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a- pro...](http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/)

<comment><USER8> Responding to "The Gervais Principle":

Categorizing everyone who works in the modern economy as either a "sociopath," "clueless," or a "loser" is utterly ridiculous and deeply offensive.

Moreover, "The Office" is not a basis for drawing general conclusions about the working world.

This very rarely happens, but I'm not willing to finish reading an article that spouts this kind of hogwash.

<comment><USER31> I understand your initial reaction, but you obviously haven't read enough of this massive five-part essay to have an informed opinion. It elaborates a theory of power politics which, in my experience, has immense explanatory power.

The terms "sociopath," "clueless," or "loser" are selected for their efficiency, and are not value judgments.

</comment></comment></comment><comment><USER32> Excellent post all in all, but the part I consider the most important is:

 _Job security, job satisfaction, good pay. Pick any two._

I've been keenly aware of that for a while now. For someone like me, someone who chooses the first two, it stings a lot until you come to terms with it and make it your conscious choice. It all has to do with one's priorities and no combination is bad in itself. You just need to be aware of these things or it might be a source of unhappiness for you.

</comment><comment><USER33> Jacques mentioned in the article that someone doing COBOL gets paid megabucks, i did a very quick search on UK job sites for _contractors_ and they seem to make the same day rate as PHP developers. Is it different elsewhere? Is it just in permanent jobs that it commands more money? Anyone know where and why COBOL gets the big bucks?

<comment><USER34> Personally, I think it's a myth. I did a lot of y2k work in cobol in '98-'99. It has been on my resume ever since then, but I've not had one recruiter call me up asking about my cobol skills, just my more recent java and db skills.

</comment></comment><comment><USER35> I am a experienced programmer, too. No "software architect" or another label can convert the stupid into brilliant. In most cases is related to recognition, power, and pay, so may be that's the reason of accepting such labels as "normal" (I have no problem with others telling me X, Y or Z, although I find it non-sense as well).

<comment><USER36> engineer, architect ... I wanna be a software astronaut when I grow up.

<comment> T-hawk Are you referencing Joel Spolsky's article on software astronauts?

<http://www.joelonsoftware.com/articles/fog0000000018.html>

<comment><USER36> ah, no, thanks!

</comment></comment></comment></comment><comment><USER37> I don't think you are (a programmer).

From the article:

 _"Programmers are guys and girls that can take real-world problems, that can analyze those problems and that use that analysis to come up with a way to improve the world, usually in an incremental but sometimes in a revolutionary manner by solving those problems (hopefully) once and for all."_

You are a systems analyst. The difference (to me at least) is that a programmer solves the presented problem by writing a program, a systems analyst solves the problem by tuning or refactoring the system. Sometimes all that takes is programming, but sometimes it takes more than that, a new data base schema, a different partitioning of roles of machines participating in the solution, user education, or even getting the rules of the game changed.

<comment><USER38> Given all that, I'd still rather be called a programmer. Anything else sounds like I'm showing off.

</comment></comment><comment><USER39> I just think the debate about identifying oneself "as", like pointed by other comments, is specific to a cultural context. In India specifically "programming" is as much about sector of work like "Information Technology" as it would be individuals profession. So most of the time "programmer" or "software engineer" inter-changeably explains the where one works for someone outside the profession. In case the person shows further interest, one could go further into what exactly is the span of work. So unlike Patrick's essay tries to convey, "programmer" per se is not a restrictive definition.

</comment><comment><USER40> The title makes it sound as if the author is in complete disagreement with Patrick's essay (and perhaps he feels that he is) but it's not how I see it.

Both articles are about the way you present yourself, not really about the "programmer" label. Sure, your label is part of what do for a living, but the important point brought up by both articles is that you have to recognize what your value is in the workplace and use that as your selling point in order to achieve job satisfaction and/or recognition (that's the way I understood them anyway).

</comment><comment><USER41> I am going to change my title to janitorial engineer.

<comment><USER42> From time to time I go by software mechanic since I spend more time fixing existing software than writing new software.

</comment></comment><comment><USER43> I'm a software developer... who cares, really... to outsiders we are weird kind of folks no matter what

<comment><USER44> haha true....When I talk to women at Bars...I am an iPhone/iPad Artist....They dont realize that that involves tweaking LLVM flags and debugging segmentation faults haha!

</comment></comment><comment><USER45> I agree "Programmer" is a sufficient job title, but my favourite "alternate" title I've seen anyone use is "Technical Enabler". It says "I use technology to solve problems and create value", which I think is very apt most of the time. You might be programming or you might simply be sharing/applying knowledge about computers, software, the web etc. that most people don't have. At least that's what I feel it's like most days.

</comment><comment><USER46> Honestly, who besides programmers even know the difference between software engineers and programmers?

I personally don't really think there is a difference. They are essentially the same thing. I'm both and I don't really see a case where I'd call myself one and not the other.

So who is making the distinction? Us (engineers) or other people?

If you really want to make the assertion that non-engineers are making the distinction between programmers and software engineers, who do you think told them what the difference was?

</comment><comment><USER47> The problem I have with "software engineering" is that it's not real engineering. Sure you might do thinking to create proper requirements, design, build a prototype, build the real thing and iterate, use agile or whatever.

But comparing programming to actual, real-world engineering is a different kettle of fish. Engineers make things with actual physical requirements - <USER3> they're not met, people will die. You're not going to be doing proper engineering unless you can sue the engineers for the wholes in their software that caused people to lose money from their bank. Sure it works and may well solve a problem, but it's not engineered.

Real software engineering is using formal methods to do your utmost to prove that your stuff actually will work (Intel does that for some of their chip development) or make 5 different control systems for your rocket and have them vote on the correct course to add extra backup to prevent fuckups (NASA did this for the Apollo iirc - the EU Ariane didn't, so they had a rocket crash at one point).

Until that happens, you're just going to be developing sandcastles - you're going to have buggy software that will break at some point - because software development is so fast that it's not worth the effort to engineer from the get-go.

In other words, coding is coding - you can have good coding that uses best practices - but if you call it engineering you're deluding yourself in most cases.

<comment><USER22> Er...what...?

Bad code won't kill people? I think any longtime reader of HN can think of a few real-life stories that would contradict this.

I studied computer engineering and yes, I remember those of us more on the hardware side thinking the ones on the "soft" side of the engineering were the lazy ones. Having been more involved in programming projects since then, I've seen the great value in being able to "engineer" software that meets highly specific specs and anticipates future needs, upgrades, and maintenance. Neither of those are necessarily related to good programming, and the failure to achieve both in mission-critical software _will lead to deaths_

* and as far as I can tell, "real" engineers do not get individually sued for physical failures, unless there's a rare instance in which an individual engineer can be proven to be malicious or grossly negligent.

<comment><USER47> I was thinking more of the web stuff that people do, so may be overstating my case. There are cases where you really need to make things safe - NASA's Apollo rockets and medical equipment to name a few. Also, when I talk about suing engineers I meant suing a big company such as Microsoft for the glaring security problems in earlier versions of Windows. Some Windows machines would be hacked within minutes of connecting them to the internet - in my mind that's simply negligence on the part of the developers - them being liable for creating an insecure product would force them to develop a properly secure solution - in other words to actually engineer it properly.

Where you have a hardware-centric approach, I'd assume that the whole system, software included has been pretty well tested and engineered to a great deal.

But banking software and I postulate most software that hacker news contributors write is probably going to be inherently flaky in some respect. The main fault for this is that writing software is so quick and easy compared to creating something physical that will last.

It's due to the push to get something to market and the "easy" nature of software development that leaves true engineering discipline by the wayside.

Yes, you can be in a situation (especially when people's lives depend on it directly such as medical equipment) when you are properly engineering a solution, but I still stand by my premise that most software development is not software engineering - you're just making sandcastles.

<comment><USER48> > Some Windows machines would be hacked within minutes of connecting them to > the internet - in my mind that's simply negligence on the part of the > developers - them being liable for creating an insecure product would force > them to develop a properly secure solution - in other words to actually > engineer it properly.

If software developers were actually engineers, or at least some of them were and were required to sign off, they would actually have authority to influence decisions that had huge impact on this situation - deprioritizing of security, bad project management, etc, not originating from the development side of the organization.

</comment></comment></comment></comment><comment><USER49> It agrees with my view that programming and mathematics are no different. I build models with my toolkit. End of story.

</comment><comment><USER50> There's an inverse snobbery in effect here to an extent. If you've made it / made a name for yourself you can call yourself a programmer.

I don't know know whether it was the recently departed dmr or ken, but one of them answered 'programmer' when asked what he put as a profession on his landing/visa/immigration card.

<comment><USER51> That isn't because they were so big that they could say programmer, it is because that is what it used to be called before self-promotion inflated all job titles to the point of hyperbole.

</comment></comment><comment><USER52> _as long as you are calling other peoples modules you're not yet programming_

How about while you're _not_ calling other peoples' modules, you're not programming _effectively_?

Why am I supposed to waste my time rewriting code available in the STL, or better, why is it held against me that I don't waste my time on such?

</comment><comment><USER53> _As a ground rule, as long as you are calling other peoples modules you're not yet programming, but that doesn't mean that what you do can't be meaningful or useful._

Oh, I see. Do I also have to code my own compiler before I start rewriting glibc?

</comment><comment><USER54> \-- _...but the fact of the matter is that I'm a programmer. It's what I do best and it is the job title that I associate with most_

and then

\-- _What you call yourself or what other people call you is utterly irrelevant._

I am utterly confused and no better at my job.

</comment><comment><USER55> I don't know about this one. I have a degree in comp sci and a master in software Eng. I've worked too hard in my life to be treated as a janitor. Why shoudnt we get the respect other engineers get?

</comment><comment><USER56> " _Glorified translator_?"

Now I feel like a Geico caveman.

</comment><comment><USER57> "My main occupations are being owner/operator of ww.com"

This guy is not a programmer. He is a business owner that can program. He can call himself a trashman and not loose a dime.

<comment><USER58> _Everyone_ is a business owner. If you sell 40 hours of your time per week to "Major Corporation X," you are still running a business.

With that, I don't see many businesses marketing themselves with titles. You don't see "Google - Search engine engineers", you see "Google". The former would be pretty foolish marketing in my opinion. As such, I refuse to use titles at all.

</comment></comment><comment><USER59> I am an information Manipulator.

</comment><comment><USER44> Here is something constructive to take away from Patrick's essay.

If you work in a bureaucracy dont whine about code quality ,better testing etc coz guess what ...No one really gives a shit!

If you really want to do good work do where its actually going to matter.WORK ON OPEN SOURCE PROJECTS.

When you are at work.Keep in mind that the only thing the management cares about is increasing profits and cutting costs.So go ahead and make them the ugly PHP5 form that they want.It will take you very less time anyways.Spend the rest of the time working on open source projects.This is a complete win- win strategy.

Yes years later when your companies stock value is in single digits ,some people in upper management will maybe understand the value of good source control,good testing procedures etc.But guess what they are not going to give much of a shit even then.All they will care about even then is (Repeat After Me)"Increasing profit and reducing costs".</comment>


Hacking: Always Design the UX First - <AUTHOR> http://blog.systemizer.me/2012/06/hacking-always-design-ux-first.html <comment><USER2> I disagree with this. Think of the basics of the UI if you'd like, but this idea of creating it first might only apply to a narrow project definition.

In my view you must think in terms of data models / data representation first. Then you move on to CRUD. At that point you might move into some of the functionality above CRUD and other app mechanics (for example: login, authorization, verification, support interaction, etc.). At this stage, if we are talking about a web project, the UI doesn't need to look any prettier than a Craig's List page.

Once that reaches flight altitude (meaning, that the basics are working) the UI can become the focus.

This becomes particularly true when you consider multi-platform applications. Say you have an app that needs to run on the web, mobile-web, as well as various phones and tablets. If the UI is first, which one? They are bound to be different. If you focus on the UI first you might do things that skew the model to suit a particular platform.

I you believe in MVC then you ought to be able to separate the three through specifications and marry them once each has reached a certain level of compliance with said specifications. Of course, there are difference that contrast a solo developer/designer vs. a multi-person team.

I want to see the engine sputter, backfire and pop before I try to optimize anything and make it pretty (UI).

<comment><USER3> I strongly disagree. Of course I understand what you mean about proof-of- concept - your analogy of testing the engine is a good one. But think about wher the engine is to be fitted: if the UI is not well-specified, then the best engine in the world will only help you crash or blow things up faster.

you can't build good data structures until you have a clear idea of the information you want to gather and manipulate for the task you propose to solve, and often that involves going to other people in a specific market and asking them how they do things. I have lost count of the number of software packages I've looked at and asked 'why is X so awkward' only to receive the reply that it 'had to be that way' because of something on the backend. This is what happens when you build data structures that are half-adequate to the task at hand and then have to have other things shoehorned into them.

<comment><USER2> Well, funny enough, I am one of those guys who is equally comfortable doing mechanical, electrical and software engineering. In all cases, the "beautification" of the product happens after the underlying principles, data structures, circuit fundamentals, loads, thermal requirements, etc. are well understood and have gone through many prototyping and testing phases. I am not talking about minimum-viable-product stuff here.

Yes, if the goal is a minimum-viable-product type web solution, by all means, make it pretty and fake the rest until you see enough traction to figure out if there's a real business.

For nearly anything else, the internals need to be well understood before it makes sense to do anything else. I can't think of one mechanical design I've done where I spent a ton of time figuring out color, size, shape and location of buttons and knobs before fully understanding what needed to go inside the box, what the electronics was going to look like, communications protocols, power supply requirements, environmental requirements, etc.

So, yes, if I was going to design a car I'd start by selecting an engine, drive train and suspension components and then designing the of the vehicle rest around it. You'd fit artists concepts and renderings to the realities of the underlying mechanics. It then becomes an iterative process where you push and pull and make adjustments to both the artistic expression and the technical realities of the design in order to converge on a product that can be released.

Let me state the obvious: These analogies are all imperfect.

<comment><USER4> A good user experience isn't 'making it pretty' or 'beautification' – this is 2012, I thought this was repeated enough.

</comment></comment></comment></comment><comment><USER5> Always be cautious of advice that starts with the word "always". The UX you design first might preclude an innovative approach that you would have discovered if you had just started coding first without a plan.

<comment><USER6> Fittingly, your advice is also starting with always.

<comment><USER7> I assume that was the joke.

</comment></comment></comment><comment><USER8> I concur. It's much easier to plug in functionality and DB objects into a finished UI/UX than the other way around. Also, it allows the hacker to just work on the core functionalities instead of worrying about how their code is supposed to output to fit into an unpainted canvas.

Obviously if you're working on an API, this doesn't apply - but you'd be surprised at how fast the hacking sprint can get when you know exactly where to plug your code into.

<comment><USER9> I'd probably recommend having an example app that uses the API anyways :)

<comment><USER7> And the API itself is UX for developers...

</comment></comment></comment><comment><USER10> If the main problem you are solving is a usability problem, a domain-specific language syntax, for example, or maybe a new photo-sharing app that's better than all the other photo-sharing apps, then the top-down UX-first approach is better. If you are mainly trying to solve anything else, it's probably better to focus on that first and make sure the data models, APIs, algorithms, or other key features are solid.

An exception to this could be when you just need to get something up and running for morale reasons, so you can begin iteration. (Although in that case I would still argue that focusing on the UX isn't critical)

</comment><comment><USER11> Speaking of UX, this is what that page looks like when JavaScript is disabled.

[https://img.skitch.com/20120604-e4x8dgp8u82akj7ngmyhywbtdb.p...](https://img.skitch.com/20120604-e4x8dgp8u82akj7ngmyhywbtdb.png)

<comment><AUTHOR> Sorry about that guys. I just started using Blogger's new blog theme. I assumed they would account for javascript-disabled clients, but I was wrong. I'll fix that asap.

thanks!

</comment></comment><comment><USER12> Designing the UI first also boosts morale b/c it gives you a tangible sense of progress, and you get to see what the end product looks like.

<comment><USER13> Yes, but be wary of showing a prototype UI which works as if the functionality/back-end is also working. Even if you stress that its not, the client will understand that the functionality is already working if they can see it, and won't understand what you're doing afterwards or why the back-end is taking so long. Be especially careful with making assumptions about complicated functionality and back-ends, as they are difficult to estimate and clients grow very frustrated after they've already seen everything "working".

<comment><USER14> I'm not afraid of a temper tantrum, it shows the client cares. Showing a basic UI that was generated by the use cases will confirm that you understand the client needs, reduces miscommunication and clearly highlights the feature creep you should be charging for. It helps the client sell the project to whoever she reports to. It's easier to change a UI and it's a stronger emotional lock-in for the client (so she doesn't cancel). Win all around!

</comment></comment></comment><comment><USER15> The authors makes it sound like after designing the UX, the implementation will become trivial. I think this is a bit naive because most serious applications go through many iterations of UX. Some of these changes will be small and not require significant re-plumbing, but others will necessitate a lot of behind-the-scenes churn.

My point is that it's better to design the plumbing of an application with some longer-term considerations than just "what do we need to implement that UI wireframe."

Minimal viable products are cool and all, but let's not use that as an excuse to write something that will need to be thrown out wholesale to add that big traction-building feature.

</comment><comment><USER16> Wanted to jump in on this. Like any problem, the answer is "it depends". If you are building an application that relies on having an extremely slick UX, you should probably start there. If you're creating an app that you want to be a workhorse or relies on a highly experimental feature, start at the implementation level.

With that said, I do feel like teams of pure programmers have a tendency to overlook the UX in favor of diving right into the code. The article is a great reminder that it takes more than wonderful code to solve a problem. In fact, the less code the better.

</comment><comment> anon-for-now I immediately dismiss any posts claiming to know the superlative of anything -- best/worst, always/never, dead/alive.

Yet, somehow, I've manage to consistently hack successful things.

My advice: Avoid linkbait articles like this, and instead spend the time actually building something. Really, it truly is that simple: Build something. In any order. With any technology.

</comment><comment><USER17> For me the UI should be just one example of how the API of the model can be used, the model is the engine, the UI is the tool that the user manipulates to move the engine.

I guess there are different schools.

<comment><USER18> Importantly, it's also likely to be the first example, and failing at the outset will make it difficult to gain any sort of traction.

</comment></comment><comment><USER19> I need to learn from this. I'm usually too excited to start turning out some code, and I almost always end up at a dead end a few weeks later (talking about personal side projects).

</comment><comment><USER20> The site doesn't seem to load.

</comment><comment><USER21> Within the constraints of a hackathon-type scenario, in general I would hypothesize about the expected user interactive results (the experience) model my data, establish the basic CRUD and wrap the UI around that, tailoring the experience to what the actual user outcome will be. If you do it in the order listed in the post you'll end up spending too much time with a UI and later having to model the data around it. That's backwards.

tl;dr: hypothetical use case, data model, CRUD, UI, test for results.

</comment><comment><USER22> If you're designing the UI first, you're not "hacking" anything.</comment>


We need testers to review our product and send feedbacks - <AUTHOR> http://www.sqardius.net/home.html

<comment><AUTHOR> If you do find it not interesting at all, please tell us why. Maybe we can do better.

<comment><USER2> Instant feedback ...

I can't really tell quickly what it does, why I want it, how it works, or what benefit I'll gain. Here's a screenshot:

<http://www.solipsys.co.uk/images/Squardius.png> (that will most likely be taken down in about 24 hours)

I'm not into photo sharing anyway, and I can't see why I'd bother to look up anyone else's photos of where I already am. It doesn't solve a problem I have, and doesn't convince me I have a problem.

It's likely that doesn't help much since I'm almost certainly not your intended audience anyway, but I thought I'd take the two minutes to give some feedback.

<comment><AUTHOR> The site is using Html5 tags, that's why you get that. Yeah, to just look on others pictures of where you already are isn't that fun or interesting, but we think it might be useful to see pictures of community meetups, sport or musical events, not all the people can assist to an event, Sqardius allows users to see what others have seen before.

<comment><USER2> Thinking out loud - I could be wrong - but ...

Your response sounds reasonable, defending your original idea, but you haven't sold me on why I might want to do it. You need to find ways to make it sounds interesting to look at photos others have taken in this location.

Currently, I have a complete failure of imagination. Sell it to me.

And consider, are you simply defending your original idea, rather than listening and responding to honest feedback?

But I hve to go do some work now. Good luck!</comment></comment></comment></comment>


My slightly more than weekend project - <AUTHOR>

I run a few calculations over and over again, and got tired of doing so. So I made a little app, the kicker is that the calculations are expressed in lispy like syntax. I thought HN might enjoy it. It is free and yes needs work. I did the absolute minium to get it out.<p>http://itunes.apple.com/us/app/candlestickcalc/id485900364?ls=1&mt=8 <comment><USER2> My $0.02:

Cool concept. I remember when I did construction, I had to do calculations all the time, and something like this would be cool. That being said, here were my first impressions:

\--I didn't know that you can make your own calculations until _after_ I downloaded the app, and _after_ I did some digging. If it wasn't cause I was trying to help someone on HN, I probably wouldn't have downloaded it.

\-- Make it more obvious how to add a new calculation. If the edit button is on the upper right, add a "+" button to the upper left. This is what your user will expect.

\-- I like the Lisp syntax for the code. But I'm a nerd. This really limits your audience. Make it look like something a person would see on a high school math board and you will have more luck. Something like: @result@ = @variable1@ * ( @variable2@ + 4.5 )

These are just my first impressions. I think it's cool, and just needs some iterations to be really good. If you get a chance, check out my app, and feel free to give some feedback [http://itunes.apple.com/us/app/follow-my- money/id471808412?l...](http://itunes.apple.com/us/app/follow-my- money/id471808412?ls=1&mt=8)

<comment><AUTHOR> Thank you. I really appreciate you taking the time to give me feedback.

While unlike the lisp syntax, I think you are right, more people could use it if there was regular syntax.</comment></comment>


The fundamental problem of programming language package management - <AUTHOR> http://blog.ezyang.com/2014/08/the-fundamental-problem-of-programming-language-package-management/

<comment><USER2> It is absurd that for every programming language there must be a new package manager. rubygems, pip, CPAN, composer, npm, bower, etc. I highly recommend that folks look into what GNU Guix and Nix can do, because they are capable of being decentralized package management systems for any type of software. They both feature "profiles", which you could equate with bundles, gemsets, whatever they are called for your language. It's trivial to use multiple versions of the same package (let's say Ruby 1.9.3 and 2.0) for different projects without them conflicting. These software projects are relatively new, but keep your eye on them and give them a shot if you have a chance.

GNU Guix homepage: [https://gnu.org/software/guix/](https://gnu.org/software/guix/)

Nix homepage: [http://nixos.org/](http://nixos.org/)</comment>


Ask HN: How much money can actually be taken out of cryptocurrency? - <AUTHOR> All these hundred million dollar USD ICO's have me wondering, how much money can actually be taken out of the cryptocurrency ecosystem right now?  Say I owned USD$1,000,000,000 worth of BTC - how much of it could I actually sell for fiat in, say, the next quarter?  Is there any way to get even a rough estimate of this number? <comment><USER2> Like in any Ponzi scheme - FIFO with profit. Anyway whatever you want to sell you need to find enough buyers who will pay what you want. Simply supply and demand works here [0]. See more topics on microeconomics to get better understanding how markets work.

[0] [https://en.m.wikipedia.org/wiki/Supply_and_demand](https://en.m.wikipedia.org/wiki/Supply_and_demand)

</comment><comment><USER3> You could sell all of it. But, for such a large trade, the market will move, so your BTC priced at USD$1,000,whatever will be worth much less. The trick would be to sell in many smaller batches.

</comment><comment><USER4> One thing is for certain - a lot less money went into the system than its current face value.

It's the old stock market saying - better to sell on the way up than down.

</comment><comment><USER5> A common misconception is that BTC must be sold on an exchange. If someone has a large amount they could sell it on a secondary market or to a private buyer offmarket.

<comment><USER6> Is there some sort of bitcoin escrow service that would manage that transaction?

<comment><USER7> Hello Coralreef - about the escrow for BTC. Yes, there are such services. Typically used for large transactions</comment></comment></comment>


Researcher Does What FBI Couldn't, Bypasses iOS Passcode Limit - <AUTHOR> http://news.softpedia.com/news/researcher-does-what-fbi-couldn-t-bypasses-ios-passcode-limit-508359.shtml <comment><USER2> s/couldn't/wouldn't/

After it became clear that their attempt at grabbing more power failed, the FBI suddenly "found" someone who was capable of doing this for them. I doubt that the capability was not there: just a nice power-grab opportunity.</comment>


NYTimes.com: DealBook: Social Networking on Wall Street - <AUTHOR> http://dealbook.blogs.nytimes.com/2008/06/20/social-networking-on-wall-street/?ex=1214971200&en=6b6b42422727d396&ei=5070&emc=eta1

<comment><AUTHOR> This article seems more like PR on behalf of Doostang than it is an analysis of the business models of Doostang or LinkedIn. The HN community seems to occasionally discuss LinkedIn, but I have yet to read any analysis/ discussion on Doostang. Does anyone out there use Doostang or know anything about their business model? I was invited to join about 9 months ago, but soon found the site to be not quite as elite as they professed due to the fact that I was expected to spam my friends with Doostang invites in order to gain access to other parts of the site. This was quite annoying and I quickly dismissed Doostang as illegitimate. Thoughts on the Doostang model?</comment>


Google is using Maps to turn every video game into an earth-sized epic - <AUTHOR> https://techcrunch.com/2018/03/14/google-is-using-maps-to-turn-every-video-game-into-an-earth-sized-epic/ <comment><USER2> I wrote about this idea 8 years ago: [http://www.kmeme.com/2010/10/future-of- googles-street-view.h...](http://www.kmeme.com/2010/10/future-of-googles- street-view.html)

Will be interesting to see if it takes off. I think it might not work that well at first, but long term seems inevitable.</comment>


Google is now making it easier to find Black-owned businesses - <AUTHOR> https://www.theverge.com/2020/7/31/21348990/google-black-owned-businesses-maps-search <comment><USER2> Providing pressure to identify by race seems like a really bad idea.

What am I supposed to do with this information?

"Hey, I'm going to buy stuff from this store vs that store based on the fact that the first store is owned by someone with the skin color I like."

Or, the negative sense of that. Why are we regressing to caring about how people look?

<comment><USER3> +1. This just makes me thinking the store is incompetent at their work and I would just probably avoid it quietly. There is a study showing how employers actually avoiding some races because of this.

</comment></comment><comment><USER4> As longs this storm of 'good intentions' it's walled inside the US, I won't care much. I won't comment much on the idea, because well, anyone who's capable of thinking one step ahead can come with some consequences.

Since we are here on HN there's a chance that some really motivated for social justice googler is around here. If it's your case, please stop virtue signaling and comforting yourself and push your company to pay its taxes instead of funneling money through complicated and shady tax schemes.

IDK, if you're extracting so much wealth out of society, why don't you put some of it back if you're so concerned about it's well being, instead of picking winners and such.</comment>


The darkness at the heart of Malheur - <AUTHOR> http://www.hcn.org/hcn/hcn/issues/48.5/the-darkness-at-the-heart-of-malheur <comment><USER2> This is a great piece, and it puts most coverage of Malheur to shame. The one pang I feel after reading journalism like this is that it will not reach the people it should. It may increase our understanding of them, but it doesn't increase their understanding, nor our ability to reach them and steer them away from the cliff edge of, in this case, divesting public lands.

It's an old play, in a way: Vast, shadowy private interests manipulate the lumpen to demonize the only institution that can stop them, the government, in order to hack away at the general welfare and the public good.

The Bundy's are just sock puppets for the Kochs and other barons amassing fiefdoms at the people's expense.

</comment><comment><USER3> This is not a short or simple read. However, if you believe that the American experiment was not a mistake, and the sclerotic dynasties of Europe are a Bad Thing, it is worth the time to read through to the end.

With the incoming administration, I have a very bad feeling that the events in the story -- militant common people fighting for their own demise -- will be replayed on a much larger scale. The more people willing to die for a cause realize that it is a lie, the more warm bodies there will be left to defend the principles that at least some of us still believe in.

</comment><comment><USER4> The key point he makes is that privatization of public lands doesn't mean rugged individualists get land. It means the Koch brothers and Ted Turner and others with a few spare billions can buy more land.

As others have pointed out, the Bundys didn't make money running cattle. They were getting state welfare payments for taking care of four foster kids. And a loan from the Small Business Administration.

<comment><USER5> Minor correction: LaVoy Finicum had foster children, not the Bundys.

<comment><USER4> Oh, right. The Bundys just had the $530K unpaid SBA loan.

<comment><USER5> By "unpaid" do you mean defaulted on, or just outstanding?

But what's your point? I don't know anything about their business, but the fact that they took out a loan isn't necessarily a sign of a poor business, nor is it hypocritical for someone who opposes the welfare state to make use of services they've been forced to pay taxes to support. See: Ayn Rand and social security.

</comment></comment></comment></comment><comment><USER6> Make sure to read the conclusion. This could do with a little editing to reduce the number of descriptions of less than sane protestors and to reach the important conclusions faster.

</comment><comment><USER7> Reading the piece he is basically describing [1]YouKnowWho's supporters. By the end he is pretty much describing YouKnowWho [2] himself.

[1] I used the moniker You Know Who instead of using Donald's last name. It seems to enrage some people when they see his last name and uncontrollably hit the downvote button. Voldermort would probably kill me for this comparison since in the Harry Potter books Voldermort was smart and charming. Donald is the idiot's version of You Know Who. Although both are very similar when it comes to lying, narcissism, and being mean to others

[2]>>Instead, the nature of evil is to take a truth and twist it, sometimes as much as 180 degrees. Love of country becomes hatred of those we believe don't share our devotion, or don't share it the same way.<<

<comment><USER8> You sure you're not reading into it? Does everything have to be about _that_? Give it a rest, please.</comment></comment>


GNU Make Alternatives - <AUTHOR> http://freecode.com/articles/make-alternatives <comment><USER2> Title is missing [2005] - was written 9-jul-2005 (doesn't say if edited since)

IMHO the most important edition since is djb "redo", which has since been implemented by apenwarr <https://github.com/apenwarr/redo/> \- It replaces make's dependency tracking with something significantly simpler and yet more reliable, and uses your familiar shell as a language to do that.

redo does NOT try to provide project management (especially not of the "cross platform" variety offered by cmake/tmake/qmake and friends). It leaves that for other tools (and rightly so, I believe).

Another important tool not listed: premake (v3 and v4, which are very different). If you're building a C++ centered project that needs to work on Windows, Xbox, Mac, Linux, PS3 and others - it will keep whatever is left of your sanity given the situation, and help you get the job done.

<comment><USER3> Agreed.

After make based builds caused too much problems for us, we first moved to WAF (<http://code.google.com/p/waf/>), but it was too complex for our needs and extending builds with our own steps became a chore.

Then we moved to redo, which was a breeze of fresh air with it's simplicity. We build a few convenience scripts on top of it to allow easier management of build targets (OS X, iOS, iOS Simulator, Linux) and been happy since.

</comment></comment><comment><USER4> Shall I be the 1st to mention tup? It automatically tracks dependencies with file notifications, is written in C and is very fast. You can run its monitor in a way that automatically recompiles whenever a source file is changed.

<http://gittup.org/tup/>

</comment><comment><USER5> Shake [1] is a Haskell library for writing build systems. I've been trying it out on a small side project lately. It isn't mature so it doesn't do everything you want, but the approach of supplying a library of build system construction tools instead of forcing you into a more rigid framework and/or DSL gives one a lot of flexibility. It seemed interesting and novel to me, but I don't know if it has been done before or not.

Not having a configuration system is a big drawback, enough to make me consider using autoconf in conjunction with Shake. Also you have to know Haskell, which will turn a lot of people away.

[1] <http://hackage.haskell.org/package/shake>

</comment><comment><USER6> It should be noted that this article is from 2005. A bit has changed in the landscape of Make alternatives.

For example another alterntive that was created later is waf: <http://code.google.com/p/waf/>

</comment><comment><USER7> This may be the time to point to a paper[0], which, sadly is rarely implemented, and turns on its head one of the common misconceptions of make, which is _"make is slow"_.

I've been using that way of writing makefiles, and significantly improved dependency analysis and speed by an order of magnitude.

[0] <http://miller.emu.id.au/pmiller/books/rmch/>

</comment><comment><USER8> Hm... no mentions of Ninja? <http://martine.github.com/ninja/>

If you are working with a project that uses CMake, Ninja is a perfect replacement for GNU Make, because it significantly speeds up rebuilds.

edit: ah, it's 2005.

<comment><USER9> This! I dropped ninja into a project with litterally 5 minutes work (mostly reading the how to install it part). It's very straight forward and /fast/

</comment></comment><comment><USER10> The fundamental problem with build systems is that they are built on top of command-line tool invocation, and command-line tool invocation is an extremely leaky abstraction; it breaks whenever the tools themselves are missing or broken. When you abstract away from this, you have to be very careful to maintain transparency all the way down, or else a wide variety of common problems become impossible to debug.

Most of the current crop of tools fails miserably at this. Whenever something goes wrong in ant, or autoconf, or jam, it's always a nightmare to debug; and the more they try to be helpful, the worse it gets.

</comment><comment><USER11> Funny

I (usually) don't have a problem with Make, I think it's a good tool for what it does (basically, a DAG solver)

For all means use make with hand-made files.

Now, autotools/automake are a different (bad) story

The alternatives posted here are very interesting

<comment><USER12> > Now, autotools/automake are a different (bad) story

While autotools are a bit hairy for the developer, the autotools-based builds usually work quite nicely. I regularly build the GNU toolchain (gcc + binutils + glibc) for cross compilation and usually it works like a charm. I grab the sources from git repos so naturally they have their moments, but it usually works better than any other build system.

Some build systems are a lot more convenient for simple tasks (I like CMake) but when it comes to cross compiling or truly configuring for varying build sites, autotools-based systems deliver.

A few years ago there was some hassle with autoconf/automake version numbers but that seems to have been solved now.

</comment></comment><comment><USER13> Nice roundup. I recently used CMake for a modestly-sized project. After getting over the initial hump, I've found it to be quite pleasant (the documentation could be a lot better, though).

I find the ability to generate real projects for the various IDEs I use on different platforms to be the key differentiating factor. SCons, by comparison, wants you to set up the IDE to replace its build step with a call to the scons script. It just feels wrong by comparison.

</comment><comment><USER14> a recent one, tundra, uses LUA as its configuration language. It's very fast, taking great care of using concurrency.

project:

<https://github.com/deplinenoise/tundra>

and slides:

[http://deplinenoise.wordpress.com/2011/04/23/slides- tundra-f...](http://deplinenoise.wordpress.com/2011/04/23/slides-tundra-from- revision-2011/)

</comment><comment><USER15> I created Lake a couple of years ago, which allows one to create ones makefile in C++.

A header and footer are added to the makefile, and it's then compiled using ones C++ compiler. Afther that it's run, and that's the point where ones other sources are compiled.

It was inspired by Icmake (by my C++ prof). It never really caught on (I didn't really promote it), but I still think it wasn't a terrible idea (apart, maybe, from it being language specific).

Lake: <http://www.logilogi.org/pub/lake/README.LAKE.txt>, <http://sourceforge.net/projects/logilogi/files/lake/> Icmake: <http://icmake.sourceforge.net/>

</comment><comment><USER16> I believe that things which behave like Make, wrap it, or otherwise generate Makefiles are missing an opportunity. If you're building C or C++, that code should already specify all of its deps. You just need to stick to certain design rules.

Really, if you say "build foo", it should just figure it out. The only interesting part is if you have extra flags needed for some libs and/or headers, and those can be specified without too much trouble. Using pkg-config as a starting point usually helps.

I'm speaking from experience here. I stopped using make for my own builds a couple of months ago. Life is great.

<comment><USER17> Not sure how mature it is, but Ekam is a project that thinks in this direction. It's not quite as easy as you believe, but it's definitely possible. <http://code.google.com/p/ekam/>

<comment><USER16> There's a big note about how it only works on Linux and how FreeBSD and Mac OS support has atrophied. I take this to be related to the syscall sniffing stuff which is at its heart.

Maybe I'm just conservative, but that kind of design is not the sort of thing I would ever want to rely on.

<comment><USER17> Maybe. There's not really another way I can think of to get a perfect picture of what the compiler is going to ask for.

<comment><USER16> I suspect your code may already have all of this right in the source.

        #include <stdio.h>
        #include <mysql/mysql.h>

        #include "base/logging.h"
        #include "http/cookie.h"

        // ... and so on.

Right there, you can translate that into a system header you can ignore, a system header for which you should add cflags and ldflags where appropriate (compiling vs. linking), and a couple of local libraries which need to be further investigated.

http/cookie.h and base/logging.h are then analyzed, along with http/cookie.cc and base/logging.cc, assuming they exist. Any #includes there are chased down in the same manner. This continues until everything has been resolved.

If you keep track of all of these things, then you will have a list of every object file which needs to be rolled up into the final binary. You also pick up all of the flags required to compile and/or link with those things by extension.

Obviously you have to handle the whole "rebuild if something changes" thing, but that's not particularly difficult, either. I wrote my own tool to do exactly this. I'm using it for my own (C++) projects, and it's been quite pleasant. It won't work for everyone, though.

I wrote about it here: <http://rachelbythebay.com/w/2012/03/28/build/>

<comment><USER17> As long as every c file has an h file with the exact same name, and every lib has precisely one so file, with the same name, I tend to agree. Although I know many projects for which this is not the case.

</comment></comment></comment></comment></comment></comment><comment><USER18> One thing that has really disappointed me with Make and friends is that we have Maven and SBT now. Suddenly Make , Autotools, CMake , Scons ,.... they all just seem so archaic compared to the amazing simplicity that is SBT. Automatic dependency resolution, incremental compilation, simple project publishing, no writing of build scripts ever.

The only other build system I know of that comes close is Go's built in system, but that appears to be more because of their instance on no linking

<comment><USER19> These friendly high abstraction build systems show their teeth when they meet configurations that deviate from abstractions. Go's a great example -- if $GOROOT or parts of $GOPATH are not owned by the build user, "go build" will occasionally fail because a pacman or aptitude update touched the compiler and Go needs to recompile every package in sight.

When dealing with JNI, both Maven and SBT have to delegate the task to less pure build systems. For projects that cannot nest nicely above a very high and consistent layer of abstraction, these "archaic" systems are essential because of their lack of interfering abstractions. They observe a different definition of "simple", instead of being "simple to use in a specific problem domain" they go to "simple to adapt to a different problem domain."

</comment></comment><comment><USER20> I used to be a big fan of SCons, and now I tend to use Rake for my build system. To me the most useful thing in a build system is to have a straightforward and easy to understand interface for setting it up, and I'm much more comfortable with Ruby and Python than I am with the odd (to me) lisp-derived syntax of make (fwiw: I typically use these with C/C++ projects, not Ruby/Python/&c)

</comment><comment><USER21> I rather like make in all its incarnations, but I'm a bit partial to Plan 9's mk:

<http://plan9.bell-labs.com/magic/man2html/1/mk>

</comment><comment><USER22> There is also gprbuild but it is used mostly by Ada programmers (especially that config syntax and semantics is very similar to that of Ada).

</comment><comment><USER23> I know that this thread can fill with posts like "why no x" but gyp is officially used by node.js so I'm a bit suprised.

</comment><comment><USER24> Redo.</comment>