Why mistakes are the curriculum

A parent watches their kid's code fail for the third time in ten minutes and assumes something has gone wrong with the session. Usually it hasn't. Usually that's the session working exactly as designed, because the thing a kid is actually learning to build isn't the specific project in front of them — it's the habit of finding out why something broke and fixing it themselves. The project is the excuse. The mistake is the material.

We don't plan around failure. We plan through it

Most curricula are written as if failure is friction to be minimized — a well-designed lesson is one where the kid never hits a wall. We think that gets the relationship backwards. A kid who never hits a wall never learns what a wall feels like, and the skill that actually transfers past any single project is knowing what to do when you hit one. So instead of writing activities that avoid breakage, we write activities that guarantee it, on a schedule the kid can survive.

The gap between "broken" and "wrong"

A mentor's most useful move here is linguistic, not technical: separating "this is broken" from "I am bad at this." Kids arrive already fluent in the second sentence and need help learning the first one instead. A robot that drives in circles instead of straight isn't evidence of anything about the kid — it's evidence about one wire, one line of code, one assumption that turned out false. Naming the bug as a property of the system, not a verdict on the builder, is most of what separates a kid who debugs from a kid who quits.

What we actually do when something breaks

We don't rush in. A mentor watching a stuck kid is doing real work even when it looks like nothing is happening — we've written about that restraint before. The move is usually a single question that narrows the search: "What did you expect to happen, and what actually happened?" That question alone does most of the debugging, because most bugs are found the moment someone states the gap between expectation and reality out loud. A kid who can answer that question is usually thirty seconds from the fix. A kid who can't yet is the kid who needs the mentor most, and even then the answer is rarely handed over — it's built toward, one narrower question at a time.

The mistakes worth having

Not every mistake teaches something. A flaky USB cable teaches a kid that cables are sometimes flaky, which is true but not exactly profound. We try to steer projects toward mistakes that are actually informative — a sensor giving a nonsense reading because of bad lighting, a story that doesn't land because the pacing is off, code that runs but does the wrong thing because the logic had a hole in it nobody spotted. Those are the mistakes that teach a transferable skill: how to notice something is off, how to isolate where, how to fix it without breaking three other things in the process.

What this means for how we talk to parents

If your kid comes home saying a project "didn't work today," that's not automatically bad news, and we'd rather you not treat it as bad news either. Ask what broke and what they tried. If they can answer both halves of that question, the session did exactly what it was built to do — the mistake was the curriculum, and it got taught.