Debugging

Debugging

Learn the AAAAArt of debugging framework to support scholars through code errors effectively. Use this approach during practice sessions and office hours to teach debugging skills while building scholar confidence and independence.
When debugging with scholars in real-time, it's important to treat the process as a learning opportunity—something you do WITH them, not FOR them. Use the AAAAArt of Debugging approach to guide scholars through the process.
Step 1: Affirm
Start by affirming the scholar's effort and showing empathy for their experience.
  • "I think that's a great question."
  • "Hm, yeah, I can see why that was tricky."
  • "I appreciate you asking for help—that takes courage!"
Why this matters: Scholars often feel frustrated or embarrassed when their code doesn't work. Affirming them first creates psychological safety and signals that debugging is a normal, expected part of coding.
Step 2: Ask Questions
Understand where the scholar is at and what they're experiencing. Don't jump straight to fixing. Gather information first.
  • "Can you tell me more about what you're trying to do?”
  • "What do you think might be causing the issue?"
  • "Can you show me what you expected to happen vs. what's actually happening?"
Why this matters: Asking questions ensures that you understand the full context of the bug and allows the scholar to practice explaining their thinking.
Step 3: Affirm (again)
Acknowledge what the scholar has done well so far. Find something specific to praise.
  • "I love how you used semantic HTML here."
  • "Your logic for this loop is spot-on."
  • "You're asking really thoughtful questions."
Why this matters: Before diving into what's wrong, acknowledge what's right. This keeps the scholar's confidence up and reinforces good practices.
Step 4: Answer
Guide the scholar toward the solution through questions, hints, and resources—NOT by giving them the answer.
  • "What does the curriculum page say about this concept?"
  • "The error says 'unexpected token.' What do you think that means?"
  • "Let's search for '[error message]' and see what we find."
  • "Let's comment out this section and see if the rest works."
  • "Try console logging this variable. What value does it show?"
  • "I'm noticing your variable is named userName here but username here. Could that be causing an issue?"
Why this matters: When scholars find the bug themselves (with your guidance), they build problem-solving skills and confidence. When you just tell them the answer, they learn dependence.
Step 5: Acclaim
Celebrate when they solve it! Make a big deal out of their success.
  • "Hey, you did it!"
  • "Nice work figuring that out!"
  • "Look at you—debugging like a pro!"
Why this matters: Celebration reinforces that debugging is an accomplishment. It builds confidence and makes scholars more willing to tackle future bugs independently.
Step 6: Return
Check back in later to reinforce learning and confidence. Don't just debug and disappear.
  • During a later practice session: "How are you feeling about images today?"
  • During a walk-around: "Wow, I see that your links look great in this project!"
  • Check their microfeedback: Did they mention feeling more confident about debugging?
Why this matters: Returning signals to the scholar that you care about their learning journey, not just fixing the immediate bug. It also gives you a chance to assess if the concept stuck.

The Delicate Skill of Affirming

Affirming is a balancing act. ⚖️ You want to show empathy and relate to the scholar's struggle without undermining their confidence in you or the curriculum.
✅ DO
  • Relate to their experience while expressing confidence you can solve it together
  • Normalize struggle as part of the learning process
  • Share your own learning journey (when relevant and brief)
Examples:
  • ✅ "I remember when Intro to DOM was tough for me—let's figure it out together."
  • ✅ "I remember first learning to code and how challenging it could be, but persevering was very important."
  • ✅ "I still make this mistake sometimes! Let's look at it together."
❌ DON’T
  • Agree that the content is too hard or confusing
  • Express that you also don’t understand the content
  • Over-share about your lack of experience in a way that undermines confidence
Examples:
  • ❌ "Yeah, this Intro to DOM lesson is confusing." (undermines the curriculum)
  • ❌ "I'm still confused by Intro to DOM." (reduces confidence in you)
  • ❌ "Actually, as of 7 weeks ago I had never coded." (undermines your credibility)
Your goal when affirming scholars is to empathize with the feeling ("I know this is hard") while maintaining confidence in the outcome ("and I know we can figure it out together").

Debugging Asynchronously

Sometimes you’ll need to asynchronously debug with your scholar—through code comments, annotations, or Slack messages. Even when you’re not there to walk through errors together, you can still keep the AAAAArt of Debugging principles in mind and guide them through the debugging process!

✍️ Leave Comments in their Code

Leave comments directly in scholars’ code to guide them toward solutions without giving answers. Sometimes a quick emoji can help communicate tone and clarity in a way that plain text can’t.
Affirm
<!-- 💡 Tip: Don’t forget the closing tag here! -->
<!-- 🔥 This organization looks solid! -->
<!-- ✨ Nice job adding classes to specific elements here! -->
Encourage self-debugging
# 🕵️‍♀️ Try printing the variable here to see what value it has.
# 🧐 Does the error message mention a specific line?
Ask reflective questions
// 🤔 What's your hypothesis for why this section isn't working?
// 🕵️‍♀️ What happens if you comment this line out and run it again? 
// 👀 Is this variable name spelled the same way as on line 10?

✨ Send a Slack Message

For broader feedback or in certain cases where you can’t collaboratively code with the scholar, send a thoughtful Slack message that guides them through debugging. Here’s an example!
Hey [Scholar Name]! 👋
Just took a look at your code—really loving the direction you’re going in! 🌟 You’re using a lot of the key concepts we’ve been practicing and I can tell you’re thinking carefully about the structure of your HTML. A couple of things to take another look at:
  • There is one spot in your JavaScript file where the code isn’t quite behaving as expected. Try running it and reading the error message closely. There’s a helpful hint hidden in the error message! 🕵️‍♀️
  • Double check how you wrote the class name in your HTML file and then compare that to the class you referenced in your JavaScript file. Remember, classes are written in kebab case (all lowercase with a hyphen between words) like this: special-class.
  • You might also try using comments to help you track what each section is doing! It’ll make it easier to spot bugs later on.
Overall, you’re on the right track. 💪 Let me know if you’re still stuck after trying those things! Happy to continue to help or you’re welcome to join the After Party tonight to get support from an IA live!

💡 Tip: Fork Code to Verify

When debugging asynchronously, you might find it helpful to fork the scholar’s code into your own environment. This way, you can verify the solution yourself before providing guidance to scholars. This will allow you to confirm the exact issue and test potential solutions thoroughly.
Important: Don't fix the scholar's code in the fork and send it back to them. Use the fork to understand the issue, then guide them to the solution!

Finding Error Messages in Different IDEs

Understanding how to access and interpret error messages is a huge part of the debugging process. Each IDE (Integrated Development Environment) we use at KWK has a slightly different way of showing you what's wrong. Here’s a quick breakdown of how to find and use error messages across the platforms we use:
CodeSandbox
notion image
How to access the console:
  1. Look in the top right of the preview panel (to the right of the URL)
  1. Click the icon to open DevTools
  1. Navigate to the Console tab
What you’ll see:
  • Error messages in red (often with line numbers!)
  • Warnings in yellow
  • Console.log outputs
Google Colab
notion image
Google Colab provides error messages under each code cell after running.
SQL Studio
notion image
In SQL Studio, the console is below the file editor panel. Any error messages will appear here in red!
If you run more than one query in a file, you may need to scroll down in the console to see them.

General Tips for Reading Error Messages

  1. Don’t panic. Error messages look scary, but they’re trying to help you!
  1. Read the error type. SyntaxError, TypeError, etc.—this tells you the category of problem.
  1. Find the line number. The error message usually tells you exactly which line to look at. Look at the line AND the lines around it. Sometimes the error is on the line above or below where it’s reported.
  1. Read the description. The message explains what went wrong (e.g., “unexpected token,” “variable not defined”).
  1. Google the error or use an AI tool to explain what it means. Copy the error message (without specific variable names) and search for it or use the prompt below with an AI tool.
      2. I'm an instructor helping a student debug their code. They're getting this error:
      [paste error message here]
      Here’s their code:
      [paste relevant code snippet]
      Please explain:
      • What this error means
      • What the student should look for in their code
      • Questions I could ask to guide them toward finding the issue themselves