Skip to content
Ravi Agheda
← All writing

— 2 min read

The Art of Debugging: Techniques for Effective Problem-Solving

A few habits that make debugging faster: reproduce first, bisect the search space, and read the error before guessing.

  • JavaScript
  • Software Development

Most time lost debugging isn't spent fixing the bug — it's spent guessing at what's wrong before actually looking. A few habits fix that.

Reproduce before you touch anything

If you can't reliably reproduce the bug, you can't reliably tell whether you've fixed it. Get a minimal, repeatable trigger first — even if that means writing a throwaway script or test that fails consistently. Fixing something you can't reproduce is just changing code and hoping.

Read the error, all of it

The stack trace tells you where, the message usually tells you why. It's easy to skim past a TypeError: Cannot read properties of undefined and jump straight to adding a null check, without asking why that value was undefined in the first place — which is usually the actual bug, one or two calls further up the stack.

Bisect the search space

When you don't know where a bug was introduced, don't read the whole diff — binary search it. git bisect automates this for regressions across commits; the same logic applies manually to a single function: comment out half the logic, check if the bug persists, narrow from there. Each step halves the space you have to reason about.

Change one thing at a time

It's tempting to fix three suspected causes at once. If the bug disappears, you don't know which fix actually mattered — and if it doesn't, you've now got three changes to unwind instead of one. Isolate variables the same way you would in an experiment.

Use the debugger, not just console.log

console.log is fine for a quick check, but a real breakpoint lets you inspect the full call stack and every variable in scope at the moment things went wrong, instead of guessing what to print in advance. In Node:

node --inspect-brk index.js

then attach Chrome DevTools or your editor's debugger — worth the ten seconds of setup for anything non-trivial.

Notes

  • Write down what you've ruled out. On a long bug, it's easy to re-test the same disproven hypothesis twice.
  • If you're stuck for more than twenty minutes, explain the bug out loud (or in writing) to someone else — or no one. Articulating the problem forces you to state assumptions you'd otherwise skip past.