3 ms·
I prefer to make analogies that don't use computers at all. The basic one I like to use when describing programming in general is that programs are kind of lik
by icey 17y ago
I prefer to make analogies that don't use computers at all.
The basic one I like to use when describing programming in general is that programs are kind of like player pianos.
Someone comes to the programmer and says "Hey, I want a piano that plays a song that sounds like this" and the programmer goes and gets the paper that the player pianos use and he starts punching holes in it.
When he wants to hear how it sounds, he has to play it through his piano a few times. If he's done it a bunch, he probably can get a lot of it done without listening to it once.
Then when he's done programming the song and it sounds exactly like what the user described, he takes it back to the user and the user says he actually wanted a hamburger, not a player piano song.
- roundsquare 17y agoI like that. I usually have the person pretend he/she is giving instructions to a very obedient but not very bright person who can/will follow any one of 30 or 40 basic commands. The question then becomes how do you string the commands together to do something useful.
- yannis 17y agoI used a very similar technique, but using two people. The one would give the other instructions to tie his shoe-laces. (Almost every-one failed to give succinct instructions and that was my way of demonstrating 'program bugs'). This was followed by a 'Hello World Tie Your Shoe-Laces' program!
- vibhavs 17y agoThat's a good one. The analogy I often use is cooking: given a set of ingredients, there's a lot you can do with it; and the order in which you do it determines the end result. This, of course, does not take into the account the iternativeness (that's not a word, is it?) of the programming process.
- Zev 17y agoThis, of course, does not take into the account the iternativeness (that's not a word, is it?) of the programming process. I would disagree. Cooking is very iterative; I know some people that are amazing cooks, and when they make the same thing, its rarely the exact same thing, intentionally. They'll vary the amount of spices, for example.
- crescendo 17y agoI use the following analogy, which seems to get the point across most of the time. Imagine you're catering an event, and you need to make 500 identical sandwiches. Now, the usual approach is to get out the bread slices, lettuce, tomatoes, turkey, etc and set to work constructing each sandwich by hand. And what if the client suddenly tells you they need 1,000 sandwiches? Your work doubles! But what if you do this instead: build a machine where you press a button and it creates one perfect sandwich, exactly to specification. Then even if you have an event that calls for 1,000, 100,000, or 1,000,000 or more sandwhiches, your work doesn't really increase. You just keep pressing a button, and any number of sandwiches pop out of the machine, exactly to specification. In this case, the machine is the program. More accurately, the machine is the CPU and its instructions for creating a sandwich are the program, but you will lose people going to this level of detail. And the sandwiches are the output.
- icey 17y agoThat's a pretty good one too. I might steal it. I mean, I might push the "Relay anecdote" button the next time I'm describing programming to someone.
- AndrewDucker 17y agoI love that - permission to quote it?
- icey 17y agoIf you're asking me; sure, quote away.