Ask HN: How do you explain how programming works to complete non-techies? | Hacker News Reader

Ask HN: How do you explain how programming works to complete non-techies?

22 pointsderwiki43 comments

I didn't realize just how hard this was until my company had an offsite yesterday where they let the sales people and the engineers play together. I guess I normally hang out with people who have at least been forced to do Java or Matlab programming or something in college, but a lot of paradigms I thought of as common knowledge aren't.

The best example we came up with (for explaining how a large web site works) was an Excel spreadsheet analogy. Imagine a spreadsheet that has a bunch of graphs constructed from the data. The spreadsheet is our database of all of our data, and each graph is a different web page view.

Programming is pretty interesting, and I think non-programmers would really enjoy knowing what's going on. Too often though, I think explanations go right over their heads, and they've learned to not even bother asking.

View on HN

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.

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

I 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!

That'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.

This, 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.

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

That'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.

I love that - permission to quote it?

If you're asking me; sure, quote away.

"Well I sit in front of a computer all day, getting mad at random text on a screen. Sometimes I add my own text that will madden a different guy in a few months/years."

People seem to like that description.

Odds are 90% that the "different guy" will be you.

I do this all day long at work. I'm a consultant who both teaches programming to people as well as develops full products for them.

There are three keys to remember: These people aren't stupid because they are uninformed about the thing you know alot about. You will lose them very quickly if you go into jargon. You do not need to explain every intricacy, you can be more accurate in the large by being inaccurate in the small.

So for instance, someone wants to understand what goes on in an iPhone app. If they're completely non-technical, I often call programs things like "very talented guy with no common sense", "idiot savant", "well trained dog that knows a lot of tricks", etc. This is getting across by analogy the idea that the program will not figure out how to do ANYTHING on its own, by implying it only knows what to do what we put in it.

So then I tell them "the way apple makes all iphone apps, there is a place to put things we want to happen when the application starts running. What do you want to happen there?". Then I toss that in there, and then ask them all the other niggling details, explaining if we don't tell it what we want those details to be, it will be "whatever standard thing apple decided will happen", like just ordering a salad at a restaurant without specifying further.

Then I ask what you want to happen in this location in the program, and that location, then we go through exceptional conditions (for an iPhone app, that would be stuff like "No network available" etc).

When you do this for awhile, you often want to stop, otherwise you're not explaining programming, you're actually programming. But they get the picture.

Another analogy: When programming you're basically telling a very stupid, very detailed, very dedicated person how to build a very ornate house from the ground up. In that analogy, the program is the "process of building the house". The house is analogous to what is made every time you run the application.

Interesting. I wonder how technical you could get by taking a Socratic sort of approach. Perhaps you could get people to understand basic first-order logic, or at least that logic can be codified. When I start off by trying to define first-principles like implication and Boolean algebra, eyes start glazing over. But in my head, the conversation could be steered by acting like a human REPL while talking about a hypothetical first-person shooter or something:

"When does the player die?"

"When their health is 0."

"When do you decrease their health?"

"When they get hit by bullets."

"So, you tell the computer: if the player gets hit by a bullet, then you should decrease the health. If the health is 0, then the player's dead. How much damage should they receive from a bullet? What if it hits their head?"

etc., descending into further complexity until they get the idea of how much they take algorithmic thinking for granted (which I think is probably the most essential thing to realize about programming).

Of course, actual conversations consist of me yakking about over-the-top technical details, amounting to the usual response: "Magic. Got it."

>Of course, actual conversations consist of me yakking about over-the-top technical details

What you need to do is go into why they care.

Then they listen VERY carefully.

I do low-level things mostly, so I start with: "The computer can only do extremely basic things that are pretty much limited to math operations, moving small amounts of data within itself and sending simple signals to devices, all really fast. It took a nation of smart people working hard for many decades to take those simple actions and build up what it is today."

I can then jump in to talking about either vulnerability discovery, or reverse engineering, or operating systems, or even web programming.

I like the part about "a nation of smart people .. for decades." It has a very "if I have seen further, it is by standing on the shoulders of giants" feel to it, and also touches on the fact that we ourselves generally deal with a small subset of All That Is Programming on a daily basis.

This idea of expressing interesting and useful things as mathematical operations sounds to me like it really gets to the essence of what we do. It not only gets the basic feel of our work across to a normal person very succinctly, it also gets across something of why we like it. The conversation can proceed to details and interesting examples, or not, but either way, the person has learned something truly important.

Fantastic.

How do you explain how programming works to complete non-techies?

I don't. I gave up trying years ago.

I prefer to let "complete non-techies" continue to think it's magic.

I have a great aunt who eventually got it in her head that my job was "trying to make computers better." I let it go at that.

I dunno. I keep trying, mostly to practice being able to talk about something I know well in terms to outsiders. It helps when pitching.

But also, seeing similar plights for mathematicians and biologists, it's important to let lay people know our contributions since lay people affect other aspects of our world that might come to affect ours, whether they're politicians, policy makers, or even a disapproving mother-in-law.

A long time ago, I was at a client's site, and had to write code at a dumb terminal in the middle of the sales floor (I said this was a long time ago). One of the salesmen walked by and saw me typing up a storm. Impressed, he said, "Is there, like, a big chart that you have memorized?"

I said, "No, I just make it up as I'm typing it."

That explanation seemed to work well enough.

I think the challenge is not so much to explain how programming works (I think most have some vague idea that it involves making the computer do "stuff") but to explain why it matters to do it well and why you get wound up about seemingly incomprehensible stuff.

I use the furniture making analogy; if you need a chair, a whole bunch of people can make you one. Some will make you a crappy chair from 2x2; some can make you a gorgeous looking hand-carved work of art; some might make you a modern sleek chair. While I might prefer the Louis XVI style chair to the Ikea style chair, the fact that the chair should not collapse when I sit on it is an absolute requirement.

Hence, some people are great programmers and some people are bad programmers, and even the great programmers often disagree on questions of style.

Two examples come to mind:

1) cooking - following a recipe is like a CPU executing program instructions

2) Giving directions (follow the street north, turn left at the second crossing, ...)

Both even come with loops: "follow the street until you see the red building", "stir until it boils"

Therefore I claim that almost everybody could program.

Re: 1) If one of your ingredients name is really long, and the word of the ingredient that starts on the next page says "Some Dish: 1 cup of poison, etc.."

that's how a buffer overflow works.

The real question is: What problem are you trying to solve? i.e. what do you hope to achieve by explaining programming to non-programmers?

When people ask me about my scientific work, or my thesis, my goal is typically to make them feel validated and my work seem interesting, rather than going into excruciating detail and making them feel dumb and my work arcane. So I explain the topic at a high-level. I then say that I examine particular aspects of the topic, but that these aspects are only interesting if you understand the context and the other things people are working on. They usually are content with that, and rarely want a summary of the literature.

Have them pickup a pencil and stand up on it's eraser. Then ask them to describe what they did. "I took the pencil and I balanced it on the eraser" is usually as deep as they go.

Then describe what they did as a programmer would.

1. You extended your arm 2. Began closing your thumb and finger until they hit pencil 3. Lifted your arm to raise the pencil off the table 4. Rotated the pencil until it was perpendicular 5. Lowered your arm 6. Stoppped lowering your arm when the eraser hit table 7. Opened your fingers 8. Check to see if the pencil was balanced and if not try again

Most people understand programming is instruction, but what they don't understand is the layered complexity. If you wanted to take this 'pencil' idea further you could say the only reason you aren't firing individual nerves to move the muscles for your fingers is because someone wrote a function for that already.

It is reasonably difficult. The problem with analogies is that all analogies are false, and they are really a diversion to the core of the discussion. This is the good approach to saying what you need to say just to get out of the room.

One tutorial example is referring to water flow in pipes to explain how electricity works. The student thinks they have got the concept, but then will totally fall off the rails when you get to magnetism, induction. And the resistance model is wrong and so on.

For example with the Excel example is that this description makes it sound way too easy. Then they ask why does each feature take so long to implement. Why don't you use excel instead?

The "nation of smart people" approach is a good start, with adding in how programs are built out of successively more complex components.

Programming is pretty interesting, but I think it's somewhat delusional to think "normal" people care. ;)

I don't know. People are generally interested to find out how others' professions and hobbies work. I don't know much about fishing, but if a friend was into it I'd be willing to hear how it was done. The same if the friend was a heart surgeon.

Programming is a fairly difficult and abstract subject, but no much so that a layperson couldn't find it interesting.

I see what you're saying and I agree. I was being somewhat facetious, hence the wink.

People usually think programming is very cool when they understand what it is, normal people included.

I'd try to use similar analogies to the examples that _why used at the Art && Code Symposium (the examples would be those used in Hackety Hack). http://www.vimeo.com/5047563

Sometimes people ask me why programming is fun. I tell them programming is like building a sandcastle or writing a story, with the added pleasure that what you build reacts to your inputs. In fact some of the pleasure of writing in a natural language comes from striving for clarity and succintness, just as when you write code.

Some people don't understand how it's possible to stay in front of a screen all day. I tell them it's not like watching tv which gets boring because you are passive, it's active because you spend the day thinking.

Programming is essentially writing down instructions for a person who is extremely literal but very consciences. In the website's case the database is like a file room and the web page is like a piece of paper. You're telling the computer to get stuff out of the file room (database), giving it instructions on what you'd like done with that information (add these numbers, etc...) and then telling them to write it's results on the paper (website)

For web design (my current expertise) I would give student a folder with index.html , img folder, js folder, css folder and explain the html file/code makes calls to the contents within those folders to explain structure(show them where in html that happens). Then i'd tell them to go play with the css and see how it affects the design and read up on each property.

I start with telling, "computers are idiots, they have no sense and no thinking ability. But they are really fast and do not get tired of repeating. They pretend to be clever by repeating written orders perfectly and fast. So someone has to write down the orders that an idiot can understand and repeat quickly."

offtopic, but:

Functional programming is like describing your problem to a mathematician. Imperative programming is like giving instructions to an idiot.

        --- arcus, #scheme on Freenode

use the peanut butter and jelly sandwich exercise.

ask them as a group to give instructions one by one for building a peanut butter and jelly sandwich. you perform each instruction precisely as given.

them: "put peanut butter on the bread" you: put the jar of peanut butter onto the loaf of bread. ask for the next instruction.

they'll get it pretty fast.

"it's like writing a screenplay to be acted by tiny little electronic things, also known as computers.".

Show them the inside of a mechanical alarm clock.

Programming is like building an invisible engine from invisible parts with invisible hands.

Writing an essay on non-familiar subject in non-native language.

1. Plan. 2. Learn subject (find an expert). 3. write a draft (documentation). 4 evolve (goto 2). 5 Update draft. 6. Make it fatless. 7. Rewrite in foreign language (code). 8. Check spelling (test). 9. Rewrite some parts from scratch. 10. go to 4.

Try this: Imagine you have a machine to create fabrics that has a set of spools of various colored threads. Now this loom also has the feature of being able to read a sheet of paper punched with holes that automatically selects different colored threads whenever it reads a line, so that by changing the pattern of punched holes in a given line, a specified pattern is woven in the fabric. So by feeding the machine different rolls of punched hole paper, we can create distinct fabrics.

The computer is the loom; information and data are the colored threads; a program is a sheet of punched holed paper; and I, the programmer, am the guy who punches out the holes.

http://farm4.static.flickr.com/3015/2589909998_6572e538c3.jp...

Reply on news.ycombinator.com