We’ve all been there: you’ve spent three hours staring at a screen, your code isn’t working, and you’re starting to suspect your computer is personally offended by your existence.
A 1:1 session with a mentor or instructor is your "get out of jail free" card, but to make the most of it, you can’t just show up and say, "It’s broken." Effective debugging is a skill in itself. Here is how to prepare so you can stop fighting the syntax and start understanding the logic.
Isolate the "Crime Scene"
Don't dump 500 lines of code on your mentor and ask them to find the needle in the haystack.
- Create a Minimum Reproducible Example (MRE): Strip away everything that isn’t related to the bug.
- Narrow the Scope: If the error happens during a database call, you don't need to show the CSS for your navigation bar.
- Identify the "Last Known Good": Be ready to explain exactly when the code was working and what you changed right before it broke.
Bring Your "Paper Trail"
A good debugger is like a detective. You need to show the evidence you’ve already gathered. Prepare a quick summary of:
- The Error Message: Copy and paste the exact traceback. Don't paraphrase it.
- The Expected vs. Actual: "I expected the function to return a list of integers, but it's returning None."
- The "Already Tried" List: List the three things you’ve already attempted. This prevents the mentor from suggesting things you’ve already ruled out.
Organize Your Workspace
Nothing kills the momentum of a 1:1 like five minutes of "Wait, let me find that file" or "Hang on, my server is crashing."
- Have the environment running: Ensure your IDE is open and the local server is active.
- Clean your terminal: Clear old logs so the new error stands out clearly.
- Comment your code: Use comments to mark the specific line where you think the "leak" is happening.
Remember : Your mentor’s goal isn’t just to fix your code—it’s to teach you how to fix it yourself next time. Focus more on why the solution works rather than just getting the green light on your tests.