Debugging as pedagogy: the bug is the lesson

Evidence grade: PROMISING, with strong adjacent foundations. Direct trials of debugging-first instruction are accumulating rather than accumulated; the supporting structure is solid — error-management training research from adult learning, the productive-failure literature, and the CS-education tradition from Papert onward all point the same way.

Every programming curriculum teaches writing programs; the better ones teach fixing them as first-class content rather than as the unfortunate interval between writing and working. The case for promoting debugging from incident to curriculum is partly practical — professional programming is mostly debugging — but mostly pedagogical: the bug is where the mental model shows itself.

The reframe that starts it

Papert's Mindstorms (1980) contains the founding move: in LOGO classrooms, the question was never "is it right?" but "is it fixable?" — and the answer was always yes. The reframe does two jobs at once. Cognitively, a bug is information: the machine did exactly what you said, and the gap between said and meant is a precise pointer at the flaw in your model — no other feedback in education is this specific, this immediate, or this ego-free (the error message criticizes the program, never the child). Emotionally, it converts the moment of failure from verdict to clue — which matters because the error-climate research (and the mindset praise findings) says how errors are received determines whether children keep taking the risks learning requires.

The adult-training literature adds hard support: error-management training — deliberately designing errors into practice and framing them as learning events — outperforms error-avoidant training on transfer in meta-analysis (Keith & Frese, 2008). Bugs aren't the cost of learning to program; structured encounters with them are the active ingredient.

The moves that work

Fix-the-broken-program tasks: hand children a program that almost works. This isolates the debugging skill from the writing skill (load management), guarantees every child meets the bug (in write-your-own tasks, the strugglers meet chaos and the quick meet nothing), and teaches the reading of other people's code as a bonus.
Predict–run–explain: prediction before running converts every run into a hypothesis test; the explain step after surprises is where models actually update. The trap it prevents: tinker-until-green, where a child mutates code until it passes while learning nothing — visible in any block-programming classroom, and the reason unlimited free runs need prediction culture alongside them.
The bug hunt as genre: naming it ("we're bug-hunting"), celebrating the diagnosis separately from the fix, and teaching the ladder — read the error, find the last-known-good point, change one thing, re-run. That ladder is the troubleshooting realm's ladder; debugging is troubleshooting with better instrumentation, and the transfer bridge is worth saying aloud.
Unlimited, unpunished runs: experimentation is the method, so the run button must be free — with prediction keeping freedom from becoming slot-machine tinkering.

What the evidence doesn't say

It doesn't support throwing novices at broken code they can't model — fixable requires almost-right relative to the child's current constructs (the edge); debugging tasks need the same prerequisite discipline as everything else.
It doesn't make frustration a virtue — productive struggle has bounds; the coaching arrives after honest attempts, not never.
It doesn't yet come with big effect sizes for primary — the grade is honest; the practice rests on converging adjacent evidence.

In the classroom

Schedule broken programs on purpose — one fix-it task per construct, minimum; your best debuggers will reveal themselves as children you didn't expect.
Install predict-run-explain as the routine for every run, chorally at first.
Split the celebration: "you found it!" before "you fixed it" — diagnosis is the rarer skill.
Model your own bugs live — the teacher debugging their projected mistake, narrating the ladder, is the single best error-climate intervention available.

How Wiz Kids applies this

Fix-the-broken-charm tasks are first-class content in the Charm Forge (debugging has its own skill node), every golem bonk is step-precise information delivered without judgment, runs are unlimited and unpunished while par scoring quietly rewards prediction over tinkering, and the fiction installs Papert's reframe wholesale: the golem "did exactly what you said — the clue is in the difference."

References

Papert, S. (1980). Mindstorms — the founding reframe.
Keith, N., & Frese, M. (2008). Effectiveness of error management training: A meta-analysis. Journal of Applied Psychology, 93(1).
Kapur, M. (2008–). The productive-failure research program. Cognition and Instruction and successors.
McCauley, R., et al. (2008). Debugging: a review of the literature from an educational perspective. Computer Science Education, 18(2).

© Glu IO Pty. Ltd. — Wiz Kids (wiz.kids). Link freely; republication requires permission — see terms. Found an error in our reading of the research? We correct fast: tell any teacher piloting Wiz Kids.