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.
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?
My dad did that exercise with me one evening. When I told him to open the bread he tore the packaging apart with pieces flying out. It took me a long while to settle down after that but it was an excellent lesson.
I have seen the same game called "robot" and played with small kids. The "robot" was somewhat forgiving, because otherwise there was no way that the kids could have gotten the sandwich made.
The kids found it funny, but I'm quite sure that the actual point sailed over their heads.
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.
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.
That is why a lot of programmer jobs, especially for small firms where design and development will never be completely distinct teams of people, are listed as "developer / analyst" (or "analyst / developer").
Translating what the user wants into a practical design that is useful to them can be more important than actual programming skill.
Even further removed from programming: inside industry knowledge/experience can be vital too, particularly in regulated industries, so that you can translate what the user says they want into what they actually need (I have before had to quietly ask "have you run that past your compliance department?" when presented with a requirement that I saw would cause problems with the auditors - spotting these things in design stages rather then the UAT stage saves a lot of hassle).
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.
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.
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.
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.
"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.
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.
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.
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'.
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.
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.
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?
Seeing programming as essentially making really detailed lists of instructions for boring tasks is pretty limited.
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.)
[+] [-] encoderer|15 years ago|reply
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|15 years ago|reply
[+] [-] sosuke|15 years ago|reply
[+] [-] btilly|15 years ago|reply
The kids found it funny, but I'm quite sure that the actual point sailed over their heads.
[+] [-] cubicle67|15 years ago|reply
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|15 years ago|reply
[+] [-] dspillett|15 years ago|reply
Translating what the user wants into a practical design that is useful to them can be more important than actual programming skill.
Even further removed from programming: inside industry knowledge/experience can be vital too, particularly in regulated industries, so that you can translate what the user says they want into what they actually need (I have before had to quietly ask "have you run that past your compliance department?" when presented with a requirement that I saw would cause problems with the auditors - spotting these things in design stages rather then the UAT stage saves a lot of hassle).
[+] [-] space-monkey|15 years ago|reply
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|15 years ago|reply
[+] [-] JoeAltmaier|15 years ago|reply
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|15 years ago|reply
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|15 years ago|reply
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|15 years ago|reply
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|15 years ago|reply
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|15 years ago|reply
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|15 years ago|reply
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|15 years ago|reply
[+] [-] eunice_chen|15 years ago|reply
[+] [-] angdis|15 years ago|reply
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|15 years ago|reply
[+] [-] spullara|15 years ago|reply
[+] [-] svdad|15 years ago|reply
Seeing programming as essentially making really detailed lists of instructions for boring tasks is pretty limited.
[+] [-] peng|15 years ago|reply
[+] [-] HeyLaughingBoy|15 years ago|reply
[+] [-] njharman|15 years ago|reply
[+] [-] jerf|15 years ago|reply
(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|15 years ago|reply
[+] [-] svdad|15 years ago|reply