Mastering the art of debugging
Debugging is a thinking skill, not a tooling one. A field guide to better hypotheses.
Most debugging advice talks about tools. Tools matter, but they're downstream of the part that actually costs you hours: the hypothesis you're debugging against.
A bad hypothesis wastes every tool you throw at it. A good one makes the bug obvious in five minutes.
Narrow before you dig
Before opening the debugger, write two sentences:
- What I observed.
- What I expected.
If you can't do this in two sentences, you're not looking at a bug yet — you're looking at a vibe. Go reproduce the thing reliably first.
Change one variable at a time
This is the oldest lesson in the book and it still trips me up. If you change two things and the bug goes away, you've learned nothing. Revert one. See which one mattered.
Trust the system until it gives you a reason not to
Your framework, your database, your compiler — all have been used by thousands of people before you. The bug is almost certainly in the code you wrote this week, not in the language runtime. Start with the part you touched most recently. Expand outward only when you've exhausted it.
Talk to yourself, then to someone else
Rubber-duck debugging works because the act of explaining forces you to linearize what you know. Half my "debugging" is actually just formatting my own assumptions into sentences and noticing which one is hand-waved.
Keep a bug diary
When you close a nasty bug, write three lines: what broke, what the root cause was, and what you'd look for next time. Six months later, you'll recognize the pattern in a new bug and save yourself half a day.
Debugging gets easier not because you learn more tricks, but because your hypotheses get sharper. Sharpen the hypothesis first. The tools follow.