Whyday August 19

Teach One Person in One Evening

The final suggestion on the 2010 Whyday page was the most direct one: take action along those lines, and teach programming to a child.

It is still the best item on that list, and it is the one people skip, because "teach someone to program" sounds like a commitment measured in months. It is not. One evening is enough to produce the thing that actually matters, which is not knowledge. It is the moment a person realises they can make the machine do something.

If this kind of exercise is run with a class or team, this discussion offers one practical reference for separating the session from ordinary scheduled work.

Everything below is aimed at that one moment.

The single rule

They leave with something they made, that does something, that they can show to another person.

Not a concept understood. Not a chapter completed. An object. Everything else about the session is negotiable and this is not.

For broader programming and making context related to this topic, Wikipedia is an independent reference worth comparing with the material here.

Before they arrive

Have it working on their machine, or on a machine that is theirs for the evening. Not yours. A session where they watch you type is a demonstration, and demonstrations teach nothing. If they have a laptop, install what is needed beforehand, yourself, while they are not there. Installation is not a lesson, it is an obstacle, and it eats sessions.

Pick the output before you pick the topic. (Free prepared projects save you inventing one.) Decide what they will have made by the end — a sound, a picture, a page with their name on it, a thing that answers a question. Then work backwards to the smallest amount of language required to get there. Most people plan this the other way round and end up teaching variables to somebody who has not yet seen the computer do anything.

Find out what they like. Not to be charming — because the project has to be about something they already care about, or the whole evening rests on your enthusiasm rather than theirs. Football, a band, a game, a pet, a subject at school. Anything.

The shape of the evening

First ten minutes: they type something and something happens. Not an explanation of what programming is. Not the history of the language. They type a line, they run it, the machine responds. This is the hook and nothing else works until it has landed.

Next twenty: they change it and it changes. Give them one thing to alter — a number, a colour, a word — and let them alter it repeatedly. This is where the actual understanding forms: not that code produces output, but that they control which output. Let them break it. Let them make it absurd. A person who has just discovered they can set the volume to a stupid value is learning correctly.

The middle hour: build the thing. You drive the structure, they type. Everything they type, they type. Your job is to keep the next step small enough that they can see it and to stay quiet while they find the typo.

Last twenty minutes: finish and show. Name it. Save it somewhere they can find it again. Get them to explain what it does to a third person — a parent, a sibling, a friend, you-pretending-not-to-know. Explaining it is where it becomes theirs.

What to leave out

Ruthlessly. In one evening you do not need: types, functions, why indentation matters, version control, the terminal beyond one command, error handling, what a compiler is, best practices of any kind, or the history of anything.

If they ask, answer in one sentence and move on. Curiosity is good and the sentence is the correct length; a five-minute digression is you enjoying yourself at their expense.

When it goes wrong

They make a typo and get an error. This is the most important five minutes of the evening and the one most instructors ruin by fixing it. Do not fix it. Say: the computer is telling you what it did not understand, let us read it together. A beginner's real fear is that errors mean they are stupid; watching an error get read and resolved calmly is worth more than any amount of syntax.

They go quiet. Usually they are lost and do not want to say so. Ask them to tell you what the last line does, in their own words. Never ask "does that make sense?" — the only available answer is yes.

They want to do something else entirely. Excellent. Abandon your plan. A person who has an idea is more valuable than any lesson you prepared, even if their idea is far too hard. Find the nearest achievable version of it and build that instead.

They are bored. The project is not about something they care about, or the steps are too big. Both are your problem, not theirs.

Age changes less than you think

The plan above works for a nine-year-old, a fifteen-year-old and a fifty-year-old. What changes is the project and the reading load, not the structure.

Under about eight, use blocks rather than typing and keep it to forty minutes. Over about twelve, the main adjustment is to stop explaining things they have already worked out — the fastest way to lose a teenager is to keep narrating.

Which tool to use at which age is a separate question, and it matters less than this structure does.

Why this is a Whyday project

Because it takes one evening, produces something that did not exist, and cannot be justified on any spreadsheet.

And because the effect is out of proportion to the effort. Most people who program can name the specific evening someone showed them, and almost none of those people were being taught in any formal sense. Somebody sat with them for two hours and let them type.

The short version