You do not need to know the answer
When a project breaks, the most helpful adult is not always the person who can fix it fastest. Your job can be to slow the problem down enough for the learner to see it.
Start with two questions: “What did you expect to happen?” and “What happened instead?” That comparison turns “it doesn’t work” into something observable.
Find the smallest broken thing
Ask whether anything still works. Does the page load? Does the button appear? Does clicking it do something, even the wrong thing? Find the last point where behavior matches the learner’s expectation.
If several things changed at once, undo or isolate changes until the problem becomes smaller. Debugging is often a search problem before it is a coding problem.
Read the evidence
Teach learners to hunt error messages for clues: a filename, line number, missing value, wrong name, failed request, or description of what the program expected.
If using AI, try: “Explain this error in beginner language. Do not give me the fix yet. Tell me what evidence I should inspect.” This preserves the investigation.
Change one thing
Form a hypothesis, change only one thing, and run the program again. If it works, explain why. If it does not, the failed test still gave you information.
Avoid repeatedly pasting whole files into AI and accepting rewrites. Large rewrites erase evidence and can introduce unrelated problems.
End with a debugging note
After fixing the issue, write three lines: What was wrong? How did we find it? What fixed it?
Over time, those notes become proof that errors are not verdicts. They are clues—and learning how to use clues is one of the most durable programming skills.
