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?
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.
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.
I don't know... sure the kids may have missed some of the subtler points, like decomposition and atomicity. I bet though, that they now have a pretty good memory "hook" for robots being silly creatures that are a little dumb and need lots of very careful instruction. This is a good fundamental bit of understanding for later dealings with computers.
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.
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.
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.
This is why you put the script on github and blog about it, that way there's a chance the script could save millions of times the amount of time it took to write.
On the other hand, if you have to do it one or two times a month, you should write a script. It prevents future mistakes on your part, and makes the task a lot easier to hand off to someone else, because you're guaranteed to record all the necessary steps.
This is exactly my job, that of a 'Business Systems Analyst' at a big insurance company. I spend most of my time refining requirements with business stakeholders until I can document a set of atomic tasks. This documentation, generally referred to as a 'Business Requirements Specification' gets passed along to the developer who then writes a 'Technical Specification' detailing the implementation of each business requirement. One of my primary goals is to remove any guesswork or questions from the developers scope, such that they can focus clearly on the implementation of the solution. In all of the enterprise level development jobs I've worked, the developer is not expected to interact with the business at all. The overhead for simple development sky rockets, but that's a reasonable trade off to meet regulatory requirements such as Sarbannes Oxley, etc.
A BA is one of those jobs I'd always thought would suit me until, in a previous life, I spent a few years working as a developer for Big Co. there we had a whole team of BAs and god were they hopeless. One of the worst things to happen to the development process.
the idea seemed to be that programmers are code monkeys; don't let them think, lets define exactly what they need to produce and get them to do exactly that. Then get a team of people to act as intermediaries between the business and the devs.
Geat idea except for: the BAs were passionless and didn't give a damn about anything other than getting the job 'done'. They didn't really understand the business at all. Most (almost all) of the many reams of documentation they produced was useless. They had no programming background, and no ability to anticipate edge cases, missing cases or anything really.
Sorry, but my limited exposure to business analysts has left me with not much more than a mix of contempt/ambivalence for the role.
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.)
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.