A nine-year-old spent forty minutes building a Scratch game where a cat catches falling apples. The score worked. Then he duplicated the apple so there were two, and suddenly every catch added two points instead of one. He looked at it for about eight seconds, said "it's broken," and reached for the delete key on the whole project.
That reflex — throw it away and start again — is the thing worth working on. Not the loops. Not the blocks. Every adult who writes software has watched someone lose an afternoon after changing four things at once and losing track of which one caused it. The habit that prevents it is learnable at eight, and it is genuinely the part that transfers out of coding and into everything else.
Almost every bug a child hits is one of five shapes
Children experience bugs as chaos. They are not chaos. In a first year of block-based coding, the same handful keep coming back:
- Off by one. A triangle drawn with repeat 4 instead of repeat 3, or turning 90 degrees when it needs 120.
- Right blocks, wrong order. Checking the score before adding to it, so the display is always one catch behind.
- Nothing was reset. The sprite starts wherever it finished last time; the score carries over from the previous game. Classic symptom: it works once, then never again.
- A condition that is never true. Waiting for the cat to touch a sprite that is currently hidden, so the program sits there doing nothing at all.
- A name typed two ways. scoore in one place, score in another. In Python this shows up as NameError: name 'scoore' is not defined.
Say these out loud once and they become a checklist — the difference between "it's broken" and "which of the five is it?" Children with a checklist stop panicking, because there is a next step.
Loops and conditionals are already in your morning
Do not explain a loop with a definition. Explain it with the thing you shouted up the stairs an hour ago.
| What you already say | The idea | What it looks like in code |
|---|---|---|
| "Brush until the timer beeps" | Loop with an exit condition | repeat until timer > 120 |
| "Put every book on the list in your bag" | Loop over a list | for book in booklist: |
| "If it's raining take the coat, otherwise the cap" | if / else | if raining: ... else: ... |
| "Five more times and then we're done" | Counted loop | for i in range(5): |
| "Keep going while there are plates left" | while loop | while plates > 0: |
The game that teaches this best takes four minutes and needs no computer. Your child writes the instructions for getting dressed, and you follow them exactly, with no common sense applied. They say "put on socks"; you put socks on over the shoes you are already wearing. Five- to seven-year-olds find this extremely funny. Ten-year-olds find it babyish unless you flip it — let them be the deliberately literal machine while you give the instructions, and let them catch you out.
The lesson underneath is not "be precise". It is that the computer is not being awkward, it is being exact, and the gap is always in the instructions rather than in the child.
The three moves that solve most of it
- Read the whole thing out loud. Children skip the error text and stare at the code. In Python the last line names the problem and the line number; make them read the words before touching anything. In Scratch there is no error message, so "read it" means reading the blocks aloud in order, in the voice of the computer, doing exactly what each one says.
- Cut the problem in half. Drag the second half of the script out of the stack and run without it. Hide one sprite. Comment out ten lines. The question is never "where is the bug" but "is it in this half or that half", asked two or three times until only a few blocks are left.
- Change one thing, and predict before you run. This is the whole trick. Before pressing the green flag, your child says out loud what they expect to happen. If they cannot say, they are guessing, and guessing is where forty minutes disappears.
Add one piece of paper: a running list of what was changed, one line each. Three simultaneous changes is how a nearly-working program becomes unrecoverable, and it is the single most common way a good session ends in tears.
The frustration point is the actual lesson
You can see it coming. The voice goes flat or loud. The body angles away from the screen. They hit undo four times in a row without looking at what it undid. Somewhere around twenty-five minutes in, you get "I hate this."
That moment is not evidence that coding is too hard for them. It is the moment the lesson is available, and how you respond decides what they learn about difficulty in general. The unhelpful moves are reliable: taking the mouse and fixing it, saying "calm down", or saying "it's easy, look".
| What they say | What it usually means | What helps |
|---|---|---|
| "It's broken." | I have no next step | "Show me the last version that worked." |
| "I did exactly what it said." | They believe the code matches their intention | "Read me line 12 out loud, exactly as written." |
| "Just tell me the answer." | The load is too high right now | Give the location, not the fix: "It's in the part that runs on the green flag." |
| "I hate coding." | Tired, and about twenty-five minutes in | Stop. Save it. Tomorrow the bug is easier — it genuinely is. |
| Silence, then selecting everything | Escaping the mess | "Before you delete it, duplicate the project so we still have this." |
Your own face is doing a lot of work here. If red text makes you tense, your child learns that red text is a threat rather than information. "Good, an error — that tells us where to look" sounds artificial the first few times you say it. Say it thirty times and it stops being artificial.
On length: twenty to thirty minutes is a realistic session at seven to nine, forty-five at ten to twelve. Stop before the wall rather than after it. Ending on a working thing, even a small one, is what makes them open the laptop again on Thursday.
Two drills, under ten minutes each
The planted bug. While your child is out of the room, break their own working project on purpose. Change one number. Swap two blocks. Rename a variable. They come back and hunt it. Start obvious — repeat 10 becomes repeat 100 — and get subtler over the weeks. It turns debugging from something that happens to them into a game they are trying to win.
Explain it to someone who knows nothing. The classic version is talking to a stuffed toy, which children over about nine find embarrassing. Sit down instead and say "pretend I have never seen this — what does this bit do?" Roughly half the time they find the bug mid-sentence and stop talking. That is the technique working, not a coincidence.
What to expect, age by age
A rough guide; children vary widely:
- Five to six. Sequences and counted repeats, mostly unplugged or with very simple blocks, ten to fifteen minutes. They will debug by trial and error rather than systematically, and that is developmentally normal.
- Seven to nine. Scratch, conditionals, a variable for score. They can isolate one change if an adult asks them to, rarely on their own. Off-by-one bugs live here.
- Ten to twelve. Nested loops, their own functions, a first text language and therefore real error messages. IndentationError arrives and is, for a while, personal.
- Thirteen and up. The target is being able to describe a bug clearly to another person: what they expected, what happened, what they already tried. That sentence is the transferable end state, and it works in a science lab or a group project just as well.
None of this needs a formal class. Two or three short sessions a week, on a real project the child chose, beats one long Saturday push. A structured track — Kid Genius World has one — can supply the projects and the order things are introduced in, but the bug still happens at your kitchen table, and what you say in the next thirty seconds matters more than the platform does.
The nine-year-old and the double-counting apples: he found it in about six minutes, once he stopped trying to fix everything at once. He dragged the apple's script out of the way, ran it, watched the score go up by one, and worked out that the change score by 1 block existed in two places. He did not remember the fix a week later. He did remember dragging half the code out to see what happened, which is the part worth learning.