A bug begins with a disagreement: the student expects one thing, and the program does another. Random clicking can blur that disagreement. Debugging makes it useful by asking what happened, what should have happened, and what evidence could separate the possible causes.
First, remove the verdict
Children sometimes read a broken project as a judgment: I am bad at this, or the computer hates me. The computer is less dramatic. It has followed a rule, read a value, or entered a state. The task is to find which one.
A routine helps: describe the expected result, reproduce the actual one, and make the relevant state visible. Difficulty remains, but it has edges now.
Change one useful thing
Suppose a player can win and lose at the same moment. Adding waits to three scripts may hide the symptom. A cleaner test displays the game state, reproduces simultaneous contact, and shows which condition runs first.
One controlled change preserves information. If the result changes, there is evidence. If it does not, the failed guess has still ruled out a cause.
Keep a tiny record
Four lines are often enough: expected result, observed result, test, conclusion. A robot should face east after two turns; it faces north; tracing the commands reveals a left where a right belonged. No ceremonial paperwork is required.
The conclusion may be that the first theory was wrong. That is useful. Over time, students also recognize familiar patterns: unknown start, wrong sign, repeated event, stale state, loose connection, or noisy reading. Names make the search faster without replacing the current evidence.
The habit travels
A circuit stays dark: verify power and output, then inspect one connection. A robot turns too far: measure, compare, change one value, test again. A written argument has a gap: find the claim that the evidence does not support.
Programming offers unusually quick feedback. It runs the instructions the student actually gave, including assumptions that were never noticed.
How adults can help
Ask what was supposed to happen, what did happen, and which test would provide useful evidence. Point to a relevant value or suggest disabling one script if needed. Then leave the consequential change to the student.
The best demonstration is not always a spotless project. A student who can reproduce one bug and explain the repair has shown careful, independent thought in a practical form.
Keep the repair small
Adults can model the same tone. Instead of asking who broke the project, ask when the behaviour changed and whether the old version still works. Save before a risky experiment. Give a strange result a name. Calm attention is more useful than rescue, and considerably more useful than announcing that the machine is stupid.
Debugging also teaches restraint. Once a student has evidence for one fault, the repair can stay small. Rebuilding the entire script may remove the symptom, but it makes the cause harder to understand and can create three fresh bugs for the price of one.