What a programmer does for a living

I've actually used a "PB&#38;J" exercise like this to teach HS kids from my hometown that took a computer engineering lab.<p>The class would start. I'd have a whole loaf of wonder bread, a pack of plasticware, pb, jelly, and paper plate.<p>"OK, who wants to tell me how to make PB&#38;J"<p>The first kid will inevitably say something like "Put the PB on the bread." So I place the jar of PB on the closed loaf of bread. They laugh. Then they start to get it. But even then, it takes time before they break it down into "atomic" steps that I can actually interpret.

This is something I've been thinking about lately; what I actually <i>do</i>, and I think I've sort of figured it out<p>First up, I'm not really a very good programmer. I'm ok, I enjoy it and I have enough skill to get by. What I <i>am</i> good at though, is being able to understand what people want. My ability, and the bulk of my income, comes from being able to take someone's vague fuzzy idea/business rules (rules? huh! business cotton wool more like it) and flesh them out and bring them to life.<p>I think my most important role is not the technical stuff, but rather being able to listen and to understand and to really try and grok what the other person's telling you.

Programming is not tedious, and it <i>is</i> hard. Listing instructions for the computer to follow is only 10% of the job. Most of the job is figuring out how to deal with complexity in a way that is economical, maintainable, and satisfies secondary requirements like security and performance.<p>In any system design involving software, the software is where the complexity goes. To save money, you might replace an electronic component with an algorithm. To make a better product you might replace a tedious user action with an automated system. This is because (some!) software developers/programmers have tools for dealing with complexity. Things like abstraction and re-use that <i>don't</i> trivially map to the concrete world.<p>Frankly if software were about enumerating steps, I would have been out of this business long long ago.

This is "what an applications programmer does for a living". Its a series of steps to accomplish a domain-specific task. Which is fine, that's what almost all programmers do.<p>Other developers (e.g. systems programmers, common library developers, device driver hacks) do something almost completely unrelated. They look for nuggets of functionality that can be used by applications. Like "make a list of things to do, then execute them in order". Or "accept instructions from a program, but authenticate the source". Or "make a concordance of all the terms in a problem space, for use by other code".<p>And making these pieces is also not at all like the process described. Its more like "look through endless manuals for ill-described OS features and diddle with them black-box style until you find out how they really work, then stitch them together. Test for time-domain anomalies (internal object lifetime; task termination order etc) and prove you have covered all the bases. Try to make it idiot-proof. Create a document that describes how to use your invention, using analogies and examples because few will have the attention span/willingness to actually delve into it.

This is a good first approximation of what programmers do all day, although actually programming a coffe-making robot to operate in a kitchen is considerably harder--it involves solving a large number of vision and mechanical problems, not all of which we understand.<p>That said, much of the expertise of a professional programmer involves <i>big</i> programs, and how to keep them from turning into unmanageable hairballs. This is where, say, engineers who know how to program generally have trouble.<p>Still, as a first approximation, this analogy is rather decent.

"All the components of what a programmer does for a living are represented here."<p>I think this only captures a part of what programmers do for a living and I think it's the easier and often more boring part: writing out the modules once you know what the modules are. Granted, while you're doing this, you might come across some interesting challenges, but the most exciting part of being a programmer (at least to me) is when you have some broad goal in the distance and no idea how to get there.<p>A more fitting parallel would be getting a big pile or random things and being asked to use it to produce a liquid that wakes you up inside some kind of receptacle with extra credit for improved taste.

This is hardly what we do for a living. I think it's a bad analogy and doesn't apply to "what we do for a living". It could apply as an introduction to "what programing is (roughly) like".<p>What we do for a living varies depending on .. well, what we do. Some people design and implement products, some people make iterative/small changes in the design and implementation of an already existing product, some people just turn specs into a functioning program. etc.

I noticed that in the beginning of the article, he uses the I-want-to-sound-like-computer English, eg "place cup on hallway table" and "pick up coffee pot". Towards the end, he becomes more effusive, and friendly to his articles, eg "hold the kettle with the spout over the coffee filter". This inconsistency is a clue that he didn't take time to try to step back and see it as a whole. Perhaps he should have imagined a nagging mother-in-law telling him how to do this ("and don't spill any coffee grounds on my clean counter, and don't forget to turn off the stove when you're done I don't want my house burned down just because you want to pretend to be a pioneer.").<p>Also, "define such-and-such" is computerese, not really how one would express this in English. Something like "when I say such-and-such, what I mean is do these things in order..." or "this is how you such-and-such" might be better.<p>All-in-all, though, an interesting exercise.

I've been toying with a new (AFAIK) conceptualization of programming. So far i've got, "programming essentially consists of N things. First of N is 'connecting.' "<p>I don't know how many N there should be or what the other essentials should be (could be 'iterating', 'transforming' or 'recurring' but i'm still thinking about them). But I'm fairly sure about the 'connecting' one - it refers to that part of writing a program where you need to set up a connection to a database, or an Ajax request, or whatever. Usually involves knowing some amount of protocol, which isn't particularly complex but can be quite 'bitty'. It's not one of the better parts of programming, it's usually a pain, but it helps to recognize it. Also highlights that although one particular problem may have been solved millions of times, for each individual programmer it can still be a hassle. It's not all 'plug&#38;play' ... more like 'splice&#38;pray'.

I think that this would be an awesome game-like approach for teaching the basics of programming to a small kid.

The problem I have with programming is knowing the actual code formalities and rules (akin to the grammar and spelling rules of the English language). I usually don't have a problem solving the problem or outlining an algorithm, but when it comes down to actually coding it out and making the code compile without grammar bugs, I run into problems. I can read code just fine (akin to reading a language being easier than writing in a language) but writing it with the correct rules and vocabulary is a whole other issue. I guess I should just do it with a "dictionary" in hand..wish there there were programming translators :)

The coffee-making analogy is roughly correct when you're talking about green-field work (starting a project from scratch). However, all projects very quickly turn into debugging exercises and yak-shaving adventures to solve problems associated with whatever framework one is using.<p>I'd say programming is something like:<p>10% coffee-making (like the OP described-- blank sheet creation) 30% Yak-shaving (crazy yet related sub-tasks) 30% Detective work (debugging) 30% other.

This article just now taught me how to make coffee.

If you really want to teach them what programmers do these days I think you need to start with the API that is available so they know the resolution they need to reach to make something that works. Maybe introduce that API after they realize how far down the rabbit hole they have to go to explain the operations required.

Entirely missing is any notion of system modelling. Yes, at some point we actually have to give the computer detailed instructions, but what instructions? To do what, exactly?<p>Seeing programming as essentially making really detailed lists of instructions for boring tasks is pretty limited.

Aren't programmers more likely to search for relevant libraries for coffee-making and stitch them together?

A developer communicates, like this blog entry communicated. The actual contents of the blog is somewhat irrelevant.

I wonder if making trivial tasks look monumental really makes people more interested in programming.