8. Debugging

Every session had produced something broken. This is where we stopped treating that as a side effect and made it the point.

The construction game’s sequencing error. The pattern game’s two bugs her friend found. The categorisation game’s Play Again button. The midnight quest’s conditions that only made sense in her head. Every session had produced something broken that needed finding and fixing.

That’s not right. Let’s fix it.

Debugging is finding and fixing mistakes — but that description undersells it. Debugging is structured problem-solving. The discipline of moving from symptom to hypothesis to test to fix, without skipping steps or guessing randomly.

She’d watched Project Hail Mary recently. One of the film’s central mysteries is what is happening to the sun — scientists have noticed it dimming slightly each year. That’s the symptom. The cause is unknown.

The character doesn’t panic. He doesn’t guess. He collects data, examines patterns, forms a hypothesis about what organism could be consuming enough solar energy to cause measurable dimming across an entire star. He tests it. He finds the Astrophage — a microscopic organism that feeds on stars. Every step follows from evidence. Nothing is assumed. The debugging process is the plot.

A few weeks earlier she’d come to me with a maths problem. Her answer was wrong and she didn’t know why. We didn’t start by redoing the whole sum. We went line by line — which step introduced the error? Was the method correct but the arithmetic wrong? We isolated the mistake to the third line. A multiplication error that had propagated through every subsequent step. Fix the step, the rest follows.

That’s the instinct debugging requires. Not starting over. Finding the exact point where things went wrong.

What I didn’t say to her during the maths problem — but thought — was that this was the moment I’d been waiting for across seven sessions. Not the game. Not the design doc. The moment she stopped wanting to start over and started wanting to find it. That shift, from ‘let me redo this’ to ‘let me find where it went wrong,’ is the debugging instinct. It showed up in a maths problem before it showed up in a game.

After the Project Hail Mary example and the maths problem, try this with your child: next time something goes wrong — anything, not just in a game — ask them to describe what happened before touching anything. Not to fix it. Just to describe it. What is the symptom? When did it first appear? What was different about the moment it went wrong? That discipline — describe before fix — is the whole concept in one habit.

How she chose what to build

She came to this session with the concept already mapped.

A game that tests the player’s ability to spot the mistake — the odd one out, the wrong step in a sequence, the difference hiding between two apparently identical images. The player is the debugger. The game presents broken things and asks: what’s wrong here?

She worked through the questions independently. The construction steps with a pinch of salt inserted between laying the foundation and building the walls. The cake recipe with “pour the batter out of the window” sitting between legitimate steps. The owl with two claws instead of three. The cat with two whiskers on each side instead of three.

A good bug is hidden but findable. Obvious once you see it, invisible until you look carefully. The wrong step in the cake recipe works because every other step is plausible — the absurdity of pouring batter out of a window only lands after you’ve read through the legitimate steps and your guard is down.

Her first version asked players to not only identify the wrong step but reorder the remaining steps correctly. She built it, tested it, and stepped back.

Too complex. The game was asking the player to do two things at once — spot the bug and fix the sequence — when the concept was about spotting the bug. She simplified to identification only. One task, done well, rather than two tasks done partially.

The design doc

The Bug Test

Mission: You have to solve the questions to set a high score.

Variables
Score
Time — 15 minutes

Rules: Wrong answer — instant game over.

Questions and Options

Question 1: Find the odd one out.
Items: Airplane, Bus, Banana, Bike, Ball
Options: Airplane / Banana / Ball / Bike
Answer: Airplane

Question 2: Spot the difference.
Cards: Two cards showing an owl sitting on a tree with the moon above its head. In one picture the owl has two claws. In the other it has three.
Options: The moon has vanished / There are only two claws / The owl is a different colour

Question 3: Choose the wrong step.
Steps: Add a bit of salt in it / Clean land / Build frame / Build a base / Add roof / Turn on lights / Add electricity / Add doors and windows / Add water system / House ready / Paint house / Finish floors
Options: Add a bit of salt in it / Finish floors / Clean land / Build base

Question 4: Find the odd one out.
Options: Rain / Rat / Rope / Sunflower

Question 5: Spot the difference.
Cards: Two cards showing a cat sitting on a tree. In one image the cat has two whiskers on each side. In the other it has three.
Options: There are two extra paws / There are two extra eyes / There are only two whiskers

Question 6: Choose the wrong step.
Steps: Mix atta with baking powder and soda / Gather the ingredients / Let it bake for 30 minutes / Mix curd, oil, and jaggery together / Put the cake in an airfryer / The cake is ready / Pour the batter out of the window / Wait for 10-15 mins / Mix the dry mix with the wet mix / Line the baking cup with oil
Options: Line the baking cup with oil / Gather the ingredients / Pour the batter out of the window

Instructions for ChatGPT: Single HTML file. Black background, white everything else. Lato font. Variables box in large font at top. Title "The Bug Test" centred above variables box. Score based on speed and accuracy. Game over on wrong answer — no options clickable. Play Again button appears on game over — large, resets entire game. Questions shuffled every game. Card questions must show the visual difference — player sees it, it is not written. Next question appears once current question is complete. You Won screen on completion. Mobile and laptop compatible. Answers for ChatGPT reference only.

Look at Question 3 and Question 6. The construction steps and the cake recipe. The construction sequence was the very first game she built in this series — she knew exactly how it should look, which made the wrong step easy to design. The mistakes are absurd only if you’re paying attention. If you’re skimming, they slide past.

That’s what a well-designed bug does. It hides in plain sight.

Design → Build → Ship

One version came back with the wrong step questions asking the player to reorder the remaining steps after identifying the error. She recognised immediately it was too complex and sent a single correction prompt: identification only, not reordering.

The second version was the final version.

She tested it herself before closing the laptop — the first session where she actively played her own game as a player before declaring it done. The testing instinct that had needed a friend to find bugs in the pattern game was starting to arrive on its own.

What this is actually building

The scope reduction is what I keep coming back to.

She built the more complex version first — spot the bug and fix the sequence. It worked technically. She looked at it and decided it was wrong — not broken, wrong. It was asking the player to do two things when the concept required only one.

That decision to simplify is harder than it sounds. She’d built something. It functioned. Removing a feature from something that works requires a clearer sense of purpose than building the feature in the first place. You have to know what the thing is for well enough to know what doesn’t belong in it.

She knew. She cut it.

I’ve seen this moment in professional contexts. The decision to remove something that works because it doesn’t serve the purpose. It is genuinely hard. Most people don’t make it. They keep the feature because they built it, because removing it feels like going backwards. She made it at nine, on her seventh game, with no prompting. I wrote it down that evening.

The maths problem is the other image that stays with me. She’d wanted to redo the whole sum. Going line by line felt slower, more effortful, less satisfying than starting fresh. But starting fresh would have hidden the error rather than found it. The error would have come back.

She knows the satisfaction of finding a bug now — really finding it, at its source, understanding why it happened. She designed a game that produces that feeling on purpose. The questions are good because she wrote them from that place.

Debugging is where she learned that fixing things properly is slower than starting over, and worth it. ⚡️

What I understand now: the construction sequence question in The Bug Test is a callback to session one. She used the first game she ever built as the material for a debugging question in session seven. She’d held that sequence in her head for seven sessions, accurate enough to hide a bug inside it. That’s not coincidence. That’s the series accumulating.

What’s next

She asked immediately.

I told her: decomposition. Breaking big problems into small ones.

She thought about it. “Isn’t that what we’ve been doing the whole time?”

Almost. Doing it instinctively and doing it deliberately are different things. Next session we name it, define it, and build around it.

New here? Start with the series introduction. Parent’s Guide: Computational Thinking for Pre-Teens