Debugging Without a Debugger

Modern debugging leans hard on tools: breakpoints, step-through execution, a console you can poke at live, sometimes now an AI reading the stack trace for you. All of that is genuinely useful day to day. But there's a separate, older skill underneath it — reading code and reasoning about what it does without running it — and that's exactly the skill that gets tested in the places where none of those tools are available: a whiteboard round, a shared doc during a live interview, a PR review where you can't just set a breakpoint in someone else's branch.

This isn't an argument against using a debugger for real work. It's that the specific skill of tracing execution in your head atrophies quietly if it never gets exercised on its own, and it tends to resurface at exactly the moment you're least prepared for it.

What a debugger actually does for you

A debugger's real value is that it replaces prediction with observation: instead of reasoning through what a variable should be at a given line, you just look at what it actually is. That's a huge time-saver, and also means you can ship correct code for years without ever practicing the prediction step — because you never had to.

The skill underneath: tracing execution in your head

This is sometimes called "dry-running" code: tracking what each variable holds line by line, predicting what a loop will actually do before you run it, spotting an off-by-one error by reading the boundary condition rather than watching it fail. It's slower than a debugger. It's also the only option in a lot of situations that matter.

Where the gap shows up

• A bug that would take five seconds with a breakpoint takes several minutes of staring. Not because the bug is harder, but because the muscle for finding it without running the code hasn't been exercised.
• You understand every line of a coworker's PR but can't predict the output without running it. That's a real gap between comprehension and prediction, and reviewers notice it.
• An interviewer asks what a snippet prints, and the honest answer is "let me run it." In a room with no way to run it, that answer doesn't have anywhere to go.
• A take-home problem with no console output available leaves you stuck earlier than expected. The absence of a familiar tool exposes exactly how much you'd been relying on it.

How to actually practice this

The practice itself is simple, if a little uncomfortable at first: take a small function, cover the output, and predict the exact result line by line before checking. Do it deliberately and often enough that the prediction step stops feeling like extra work and starts feeling like the normal first move.

This is also close to how grading works on SoloScript: instead of a plain pass or fail, feedback points at exactly where your reasoning went wrong, which is its own version of tracing through what actually happened rather than just knowing that something didn't.