
Ask HN: How do you explain how programming works to complete non-techies? - derwiki
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.<p>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.<p>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.
======
icey
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
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.

~~~
yannis
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!

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

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

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

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

~~~
gte910h
>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.

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

~~~
derwiki
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.

------
edw519
_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.

~~~
presidentender
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.

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

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

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

~~~
yan
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.

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

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

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

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

~~~
astine
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.

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

------
grosales
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>

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

------
TomOfTTB
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)

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

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

~~~
JBiserkov
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

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

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

------
anigbrowl
Show them the inside of a mechanical alarm clock.

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

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

------
lucifer
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...](http://farm4.static.flickr.com/3015/2589909998_6572e538c3.jpg?v=0)

