Helping a Beginner Debug Without Fixing the Bug for Them

A student puts a hand up, says "it doesn't work", and turns the laptop toward you. You can see the problem in four seconds: the line that sets the running total to zero is inside the loop, so the total resets on every pass. The fastest thing in the world is to point at it. The student says thanks, the program works, and twenty minutes later the same student has the same kind of bug in a different program and puts a hand up again.

I coach students for programming contests, where nobody can turn a laptop toward a mentor. The ones who do well are not the ones who make fewer mistakes. They are the ones who can find their own mistakes quickly. That skill gets built, or not, in exactly these small moments at a club table, and it depends a lot on what the helper does with their hands and their mouth.

Why fixing it feels kind and teaches the wrong lesson

When you fix the bug, the student learns one true thing and one false thing. The true thing is where that particular bug was. The false thing is that debugging is the act of being looked at by someone who already knows. A beginner who has watched a mentor glance at a screen and spot the issue a dozen times concludes that experienced people see bugs, and beginners wait for them.

Experienced programmers do not see bugs at a glance most of the time. They run a process: narrow down where the behaviour goes wrong, compare what the program does with what they expected, test one guess at a time. Your quick spot came from pattern memory on a tiny program. The student needs the process, because their next bug will be in a program too big for anyone to eyeball.

A question ladder that keeps your hands off the keyboard

The habit that changed my club sessions most was a rule for mentors: you may ask questions and you may point at the screen, but you do not touch the keyboard. Then you climb a short ladder of questions, starting at the top and stopping as soon as the student finds it.

1. "What did you expect it to do, and what did it do instead?" Many bugs get found right here, because saying the expectation aloud exposes it.
2. "Is there an error message? Read me the last line." Beginners scroll past the one line that names the problem.
3. "Which line do you think is the last one that works correctly?"
4. "Can you print the value of that variable just before and just after that line?"
5. "Can you make the input smaller? Try it with a list of two numbers instead of twenty."
6. "What is the value on the second time round the loop?"

The loop bug from the opening falls at question four or six. The student prints the total inside the loop, sees it go 5, 3, 8 instead of 5, 8, 16, and says "oh, it keeps starting again". That sentence, in their words, is worth more than the fix.

Reading error messages deserves its own practice, and we cover it separately in how to read a Python error message when you are new. When a student is stuck on a set exercise rather than their own project, the approach in getting unstuck without peeking fits better.

The advice I disagree with: never give the answer

Some teaching guides say a mentor should never tell a student where a bug is. I think that is too strict, and following it rigidly costs you students.

Debugging practice has a budget. A beginner who has spent fifteen minutes on a missing colon, getting angrier, is not learning to debug any more. They are learning that programming makes them feel stupid. Past that point I tell them, plainly, and then I ask them how they could have found it, so the moment still teaches something.

There are also bugs that are not worth climbing the ladder for at all. A broken installation, a file saved in the wrong folder, a library missing from the school laptop, an editor set to the wrong Python version: these are environment problems. Struggling with them builds frustration, not skill. Fix those yourself, quickly, and explain in one sentence what was wrong.

Let them struggle with the logic. Rescue them from the setup.

What it looks like across a whole session

In a club of fifteen with two mentors, you cannot spend ten minutes per question. The ladder helps here too, because its first two rungs take under a minute, and they resolve a surprising share of questions. My rough sense, from years of sessions rather than any count I kept, is that somewhere between a third and a half of "it doesn't work" questions end at rung one or two.

For the rest, I leave students with a specific next step and walk away: "Print the total inside the loop, and I will come back in three minutes." Walking away matters. A mentor standing behind a student turns debugging into a performance, and nervous students guess wildly instead of testing. Coming back on time matters just as much, or the student learns that asking leads nowhere.

Pairs change this. When two beginners share a laptop, the ladder works best aimed at the one not typing, who often spots the issue first because they are not busy fighting the keyboard. There is more on how beginner pairs behave in why pair programming works differently with complete beginners.

Teaching the ladder to the students themselves

The real goal is for students to climb the ladder without you. After a few weeks, print the six questions on a card and leave one at every table. When a hand goes up, ask "which question are you on?" before anything else. Students who have already done the first three arrive with a much better question, and some stop raising their hands for small bugs at all.

I have seen this fail when mentors keep the card but quietly go back to fixing things whenever the room gets busy. Students notice which rule is real. If you are short of helpers, it is better to tell the room "I will be with you in five minutes, start on question two" than to fix bugs for speed.

Try it at your next session

Before your next club meeting, agree with every mentor on the hands-off-keyboard rule and write the six questions on cards for each table. During the session, keep a tally of which rung each question ended on. After two weeks, look at the tally and see how many questions never needed you past rung two.