

What a programmer does for a living - ZeroMinx
http://jacquesmattheij.com/what+a+programmer+does+for+a+living

======
encoderer
I've actually used a "PB&J" exercise like this to teach HS kids from my
hometown that took a computer engineering lab.

The class would start. I'd have a whole loaf of wonder bread, a pack of
plasticware, pb, jelly, and paper plate.

"OK, who wants to tell me how to make PB&J"

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.

~~~
famousactress
The thing that hangs me up with exercises like this is how to communicate
_how_ atomic the steps ought to be. The analogy misses, there. Why does the
'system' need to be told to open the jar, but not _how_ to open the jar?

~~~
encoderer
Actually when they say "Open the jar" i start beating it against the table.
But yeah, most the exercise is figuring out the granularity. After they get
the idea, it's quick work to give me the steps.

I've been thinking up a similar exercise, for later in the course, for
concurrency. EG you can have one student get a piece of bread and apply jam,
another to apply the PB, etc etc.

The best part about food-based analogies is that everybody can enjoy them and
relate and they all get to snack afterward while i give a brief lecture tying
the example into the coursework.

------
cubicle67
This is something I've been thinking about lately; what I actually _do_ , and
I think I've sort of figured it out

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 _am_ 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.

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.

~~~
gaius
Yeah, this is a fallacy many people hold. We are not here to "write programs".
We are here to solve people's problems, a program is just a means to do that.
That's what you're really measured on, how many and how difficult the problems
you solve are. If you can solve a problem not with code but wth say updating
the documentation, or running a training class, then as a programmer that's
the right thing to do.

~~~
Locke1689
It can actually hurt if you're really good at or really like programming
because it can sometimes lead to unnecessary programming. A common example of
this is writing a small script to automate something that would have actually
taken less time to just perform manually the one or two times you have to do
it.

~~~
mgkimsal
Agreed, except you need the wisdom to know when you truly will never ever have
to do that task again (nor anyone else) vs when you think you only need to do
it once. There's value in having something scripted that you end up needing to
come back to months later. I also know I would have preferred setup steps to
be scripted on projects I've taken over, vs apparently just hand-entering SQL.

------
space-monkey
Programming is not tedious, and it _is_ 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.

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 _don't_ trivially map to the concrete world.

Frankly if software were about enumerating steps, I would have been out of
this business long long ago.

~~~
Kilimanjaro
As I've always said, coding is easy, analyzing is hard.

------
JoeAltmaier
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.

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".

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.

~~~
sophacles
You forgot:

Secretly plot the torture and murder of the web guy who redesigned the login
page and got piles of credit while your widget gets a perfunctory "ok" from
management. Despite the login page having no effect and your widget saving the
company thousands of dollars.

------
ekidd
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.

That said, much of the expertise of a professional programmer involves _big_
programs, and how to keep them from turning into unmanageable hairballs. This
is where, say, engineers who know how to program generally have trouble.

Still, as a first approximation, this analogy is rather decent.

------
pushingbits
"All the components of what a programmer does for a living are represented
here."

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.

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.

------
hasenj
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".

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.

------
numeromancer
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.").

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.

All-in-all, though, an interesting exercise.

------
Tycho
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.' "

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&play' ... more like 'splice&pray'.

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

------
eunice_chen
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 :)

------
angdis
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.

I'd say programming is something like:

10% coffee-making (like the OP described-- blank sheet creation) 30% Yak-
shaving (crazy yet related sub-tasks) 30% Detective work (debugging) 30%
other.

------
brunt
This article just now taught me how to make coffee.

------
spullara
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.

------
svdad
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?

Seeing programming as essentially making really detailed lists of instructions
for boring tasks is pretty limited.

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

~~~
HeyLaughingBoy
Not necessarily. Some of us are paid to write those libraries :-)

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

~~~
jerf
As I said yesterday on another similar comment, you do want to keep the
concept of "coding" in there somewhere. After all, executives, marketers,
sales of all kind including the kids taking your order at McDonalds, and the
secretary taking the phone calls all communicate so therefore they are
programmers. That dilutes the term into uselessness.

(And let's skip the hypothetical where maybe they've got some package that
allows automation; then, yes, when using it they are acting as programmers.
Labels are always fuzzy. Nevertheless, they convey real information despite
that fuzziness. Deliberately fuzzing up a definition to try to win a point on
the internet is a terrible thing to do to a word.)

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

~~~
svdad
I can say without a doubt that reading this article (if I let her) would make
my wife look at me more strangely, not less.

