Have you ever taught a kid anything?

Not "signed them up for something." Taught. Sat next to them while they got it wrong eleven times, kept your mouth shut, and watched the twelfth time click.

What's that? You're already picturing the tablet, the subscription, the cheerful cartoon robot that says "great job!" when a block snaps into another block? And the kid who, after a year of that, still can't tell you what a file is?

Come on in. Let's talk.

A few years ago I wrote a long piece on how to teach people to code. It was about interns, grad students, and the occasional finance major who got dumped on me by the dean's office. Then I had kids of my own, and I found out that every rule in that article still holds. It just holds harder. An adult will forgive you a boring lesson. A seven-year-old will not.

So here it is again, the kids' edition. Everything below has been tested on real humans, some of them under four feet tall.

First, what are you even teaching?

Not Python. Not Scratch. Not "coding."

You are teaching a small person to understand a machine. And we could argue about what "understand" means until the kid is in college, so let's use a crutch instead.

"Understood" means you know how to do something.

"Understood" means the kid has a spinning 3D model of the computer in their head. They know there are folders, and folders hold files, and a file is a thing with words in it, and the machine will read those words back if you ask it right. They know that when they type a command, the computer does exactly that, not what they meant. They can walk up to a computer they've never seen and not be afraid of it.

That's the whole target. A kid with that model in their head will learn Python in a weekend when they need it. A kid without it will memorize Python syntax for a year and still freeze when the terminal opens.

When I asked Grant Sanderson, the guy behind 3Blue1Brown, how many digits of π he knows, he rattled off twenty and then said something better than the digits: memorizing constants is a sign something is wrong with how we teach. Kids memorize things that have no meaning to them because it looks easier than understanding them. Multiplication tables, yes, memorize those. The digits of π, no. And a syntax for a language the kid has never had a reason to use is the digits of π.

Interesting detail from the same interview: Grant's father gave him math by stacking sugar cubes in strange arrangements and asking how many were on the table. If the answer was right, the kid got the sugar. Keep that one. We'll come back to it.

The idiotic claims, kids' edition

The world is full of prejudices about teaching, and the ones about teaching children are the worst, because everybody has a childhood and therefore everybody is an expert. Here are the main ones.

Idiotic claim number one: "He's not a computer kid."

There's no such thing as "couldn't." There's only "didn't try hard enough," and I'm talking about you, not the kid.

My great-grandmother worked at a boarding school for deaf-mute children. She taught them to speak. Then she told me how they taught deaf-blind-mute children, and I sat there in shock, and they did it, and those children held conversations. And in front of you stands a kid with two working eyes, two working ears, a mouth, and an attention span that can absorb every Pokémon ever printed. You're going to tell me about problems? Ha.

"Not a computer kid" means the kid hasn't met the right piece of the computer yet. That's your job, and it's described below.

Idiotic claim number two: "Get them a course."

Remember the guy who desperately wanted to be a pilot, sat six months in a useless school, and quit because the actual airplane was apparently reserved for his next life? That guy was an adult with a dream. Your kid has a spark, which is smaller and goes out faster.

A course is for a person who already wants the thing and needs it organized. A bored kid with a keyboard wants the thing within ten minutes or wants to be somewhere else. Courses come later, if ever. Most of us never took one.

Same goes for the "learning app" with the cartoon robot. It's a course with a mascot.

Idiotic claim number three: "They'll figure it out on YouTube."

You wouldn't teach an intern by dumping a folder of PDFs on them and walking away. Don't do it to a child with a folder of videos. YouTube is where the spark goes to become a feed.

Idiotic claim number four: "Blocks first, always."

Scratch is fine. I mean that. If the kid can't type yet, blocks let them build a loop without spelling anything, and a six-year-old can make a cat dance in five minutes. What blocks don't teach is the machine. There are no files, no folders, no manual, no "what happens when I type the wrong thing." A year of Scratch and the kid still can't open a terminal. So: blocks while they can't type, and the moment they can, give them the real thing. Don't hold them in the kiddie pool because the sign says "ages 6 to 12."

Don't kill the spark

This is the one that matters. Everything else on this page is technique. This one is the whole game.

Every programmer I know has a moment. Mine was Theme Park. After many hours I noticed patterns in how the little visitors moved along the paths, and it hit me that somebody had described a whole universe with its own rules, and it was running on the thing in front of me. I wanted to make my own. It took years before I could, but the picture never left.

Your kid will get their moment from somewhere you can't predict. A game. A friend's older brother making a phone whistle a melody with five keystrokes. A computer that talks.

And here is where parents kill it, accidentally, out of love. "Programming is hard." "You'll learn that when you're older." "First you need to learn math." Here's Knuth, come back when you've done the exercises.

Don't talk about what's hard. Talk about what's easy.

When a kid with puppy-dog eyes walks up and says "I want to make a game," the correct answer is: "You can't make Minecraft today. But I've got an idea. We'll start with a very small game and keep making it bigger until it's Minecraft." Then you give them something to play with. Something with a wow in it. Let them push buttons and see the machine do things. The learning follows the wow; it never leads it.

The wow I built into KidDOS is one line:

echo "I am a robot" > /dev/speaker

The computer says it out loud. A seven-year-old will do that for an hour, and somewhere in that hour they will have learned what echo is, what a file is, and what the > does, and nobody told them a single thing.

How to help a kid understand

To understand something complicated, a person needs a clear grasp of the simple things it's made of. That's true for a DevOps who replaces FROM ubuntu with FROM alpine because "it's smaller," and it's true for a kid who types cd games and gets "no such directory" and decides computers hate them.

The DevOps didn't know the difference between a distribution and a kernel. Dig, and he didn't know what a process was. The kid doesn't know that games is a folder that lives inside another folder, and they're not standing in that one.

Same job, both times. Roll up your sleeves, sit down, and find the simple thing they're missing. Not by explaining. By asking.

"Why did you type that?"
"Because I want to play games."
"Where are you right now?"
"...on the computer?"

There it is. The kid has no idea that "where" is a question you can ask a computer. So you show them pwd, and you say: the machine is always standing somewhere, like you are. And a whole room lights up.

I once traced an intern's confusion about C# all the way down to the fact that he didn't know what electrical current was, and then further down to induction, and then I showed him the Latin: in- plus ducere, "to lead into." It hit him like a shock. He spent three days, ten hours a day, reading everything he'd ever skipped, and came out the other side understanding transistors. With a kid the missing piece is never that deep. It's "what is a folder," "what does Enter do," "why did it say no." But it's there, every time, and finding it is the job.

When the finance students landed on me and had to learn programming from zero, I explained a linked list by sitting them around a big table, a number on a piece of paper in front of each of them, their left and right hands as the pointers. It clicked. For a kid, the version of this is: folders are rooms. Files are things in the rooms. cd is walking through a door. ls is looking around. And then you make it literal: in KidDOS the first game is a cave where every room is a folder and every item is a file, and the kid carries a torch from room to room with mv. They're not learning the file system. They're playing.

Don't dump everything at once

The moment someone comes to you with a question, answer it and pile on as much as you can find, so that, overwhelmed and weeping, they quickly flee the scene.

That's the anti-advice. Here's the advice: a little at a time, and watch the face.

A kid asks "how do I make it say something." You show echo hi. You do not, at that moment, also explain variables, quoting, redirection, and the history of Unix. If they look confused, go back one step. If you announce "today we learn loops" and the kid deflates, ask how many loops they've already written, because there's a decent chance they've been doing FOR in BASIC for a week without telling you.

This is why I like the machine to do the teaching in short lines. In KidDOS the tutor is a purple line at the bottom of the screen that says one thing: "you made a folder. Now go inside it: cd box." Twelve lessons, one idea each, and the machine never says the next one until the kid did the last one. I didn't invent that. Every good book works that way. Most courses don't.

Practice and repetition, in that order

In our trade, a book gets you 80% of the way. The other 20% has to be drilled. ls, cd, cat, the up arrow, Tab: these should fly out of the kid's fingers without a thought, the way a sysadmin doesn't think about ls -lah.

But drill after understanding, never instead of it. A kid who memorized "type cd then the name" and doesn't know what a folder is will type cd snake.bas and be confused for the rest of the afternoon. A kid who knows what a folder is will figure out the typo themselves. Understand first, then repeat until it's in the hands. Multiplication tables, not digits of π.

Games are the drill. Nobody has to make a kid play Snake forty times. And when Snake is a text file they can open, the fortieth time they'll open it and change the speed. Now the drill turned into programming and nobody scheduled it.

No exams. Real things.

We all know how to lose our minds at the word "exam." Don't bring that archaism into your living room.

Understanding can only be checked one way: can they do the thing? If you taught someone to crimp a cable, they crimp a cable and it passes the tester. If you taught a kid to drive the machine, the exam is: "make the snake faster." "Find where the high scores are kept." "Make it say your sister's name." They can or they can't, and both of you can see which.

Those finance students? The ones who wrote Mario got an automatic pass. The rest explained to me what happens in memory, and everyone went home happy. Nobody was asked what year C was invented. That's on Google and helps nobody write a program.

And here's the sugar cubes again. Grant got the sugar when the count was right. The count was checkable; the reward was immediate; nobody had to grade anything. A computer is the best sugar-cube machine ever built. The kid types a thing, the machine does the thing or doesn't, and that's the whole exam, a thousand times a day, with no adult in the loop.

When they break it (they will)

Somebody, someday, will type rm -rf at the wrong place. If that place is your laptop, you have a bad week. If it's a fake drive inside a sandbox, you have a lesson, and it's the best lesson there is.

Because here is the thing a computer teaches that nothing else in a child's life does: it does exactly what you said. Not what you meant. Not what would have been reasonable. A computer is precise, and it's that precision that made computers worth having in the first place. It's also why "the computer is being stupid" is never true, and a kid should learn early that there's no such thing as "this works badly." There's only "I haven't figured this out yet."

Watch what the kid does the first time it breaks. If they turn around and say "it's broken, fix it," you have some work to do. If they say "hm, what did I type," you're done, go make coffee. Your job in between is to never fix it for them and never let them blame the machine. "What did you tell it to do?" is the whole conversation. This is the same thing I yell at grown programmers about, and it's a lot cheaper to learn at eight.

It's also why there's no AI inside KidDOS and won't be. A kid who grows up with an autocomplete that writes the program for them never has to say "this is correct" about anything, and that ability to say "this is correct" is the one thing the computer can't do for us. Let them get that habit from a small machine that answers only to what they typed.

Every kid is different, and no, that's not a platitude

My wife eats buckwheat every day. I can't live without scorpion sauce. There's no average diet and there's no average kid, and the method that worked on one will bounce off the next.

One kid will read the manual cover to cover and never touch a game. One will play Tetris for a week and then, only then, ask what's in the file. One will type speak four hundred times and be delighted every time. All three are learning. Your job as the teacher is not to have a method. It's to figure out what this kid needs in order to understand, and that's a question you answer by sitting next to them, not by reading a page like this one.

Which is my problem with courses, apps, and the "average" of everything: they are built for the kid who doesn't exist.

What this looks like in practice

I'll be honest about what I actually did with all of the above: I built a machine that follows these rules so I don't have to be in the room for every single one of them. It's called KidDOS, it's free, and it's rough around the edges. But the rules are baked in:

The machine is small enough for one kid to read all of it, and it says so on the first screen: "It is all yours. You cannot break it."
The first thing it asks for is hi, and the second is the kid's name. The wow (/dev/speaker) is one line away.
The tutor says one thing at a time and waits.
Every game is a text file the kid can open and change. Snake, Tetris, Sokoban, a cave, a roguelike in C with the source.
The exam is the game working. The reward is the badge and the sound.
vi is locked. You earn it by playing. I wanted to see a kid's face when /bin/vi appears, and it's every bit as good as I hoped.
There is no internet, no host files, no AI. The kid can nuke the whole drive and you reset it with one command.

If you'd rather do it on a real computer, do it on a real computer; the rules are the same. Give the kid a user account with no browser, a terminal, a couple of games with the source, and a chair next to yours. It's more work for you, and it works.

Wrapping up

You're teaching understanding, not a language. "Understood" means the kid can make the machine do the thing.
There is no "not a computer kid." There's a piece of the machine they haven't met.
Don't kill the spark. Don't talk about what's hard. Give them something with a wow in it and let them play.
When they're stuck, find the simple thing they're missing. Ask, don't explain. It's usually "what is a folder."
One thing at a time. Watch the face.
Understand first, then drill until it's in the hands. Games are the drill.
No exams. "Make the snake faster" is the exam.
When they break it: "what did you tell it to do?" Never "the computer is stupid." Never fix it for them.
Every kid is different. The method is sitting next to them.

If you've never taught a kid anything, know this: it's one of the best things you'll ever do. Ten years from now, someone will tell you that you're the person who showed them a computer does what you say. And then they'll go and tell it what to do.

Comments are open on the KidDOS post, and they go through GitHub. Tell me what your kid did with it. Especially if it went wrong.