If you're seeing this message, it means we're having trouble loading external resources on our website.

If you're behind a web filter, please make sure that the domains *.kastatic.org and *.kasandbox.org are unblocked.

Main content

Classroom debugging guide

If you're teaching a classroom of students learning programming, you may find students coming to you for help. You can use the tips below to talk through student questions together (to be their "rubber duck", as we call it)-- even if you aren't that familiar with programming yourself.
The general goal is to help the student become a better debugger, so they can help themselves when they're not in the classroom. Behind every good programmer lies a great debugger. :-)
If they don’t understand a challenge step:
  • Ask the student to read the challenge step aloud.
  • Ask the student to look at the hint code and contrast it to their code.
  • Ask them to explain what their code is currently doing.
  • Encourage them to try something out and see what happens.
  • If they get very far off-path, remind them they can “Start Over”. Make sure they read each step carefully the second time around.
  • Encourage the student to re-watch the previous talk-through, or skip to the end of it to see what the final code was. It is often similar to the challenge. Ask them read that code a loud and explain what it does. Have them modify it to see if it aids comprehension.
If they don’t understand a project description:
  • Ask them to read a loud each step, and to stop at parts they don’t understand.
  • Have them read through the starter code, line by line, and explain what each line does. If there’s something they don’t understand, have them check the documentation or re-watch the relevant talk-through.
  • If you’re unable to help, remind them they can click “Request Help”. Make sure they ask their question descriptively.
If they don’t understand an error message (“Oh Noes”):
  • Ask the student to read it a loud and to explain what they think it means.
  • Make sure they click “show me where”, as it often points to the line of the error. It can sometimes be wrong, however, so the error might be an earlier line of code (usually not later).
  • If the error message doesn’t make sense and there are multiple messages, click through them to see if other messages make sense.
  • Encourage them to improve the indentation of their code (watch Readable Code for an explanation of that). Especially if they’re dealing with functions, for loops, or if conditions, proper indentation can make it easier to find errors with mismatched brackets, and to find logical errors.
If they don’t understand what their code or the starter code is doing:
  • Have them go line by line and explain what they think each line does.
  • Make them check the documentation for any keyword/function/global variable that they don’t understand. Click through to see the example and have them explain what the example does. They can try modifying the example program
  • Encourage them to use println() to output the values of variables. Are they what they expected? If not, why? They might need to think through it on paper or println() other values to understand why.
If they think they did a challenge step correctly but it won’t pass them:
  • It’s possible that their code is a correct solution but that the automated grader isn’t aware of it. In that case, please click “Report a problem” and have the student move on.
What other techniques do you use for debugging in the classroom? Tell us below!

Want to join the conversation?