Give two engineers the same bug. One reaches for the debugger. The other reaches for a hypothesis. The second one finds it faster, almost every time.

Debugging tools are good at showing you what's happening. They are useless at telling you what to look for. That part is entirely a thinking problem, and most engineers never learn to do it deliberately.

Watch someone bad at debugging and you'll see a pattern: change something, rerun, see if it worked. Change something else, rerun, see if it worked. This is search without a hypothesis — the debugging equivalent of trying every key on a key-ring instead of reading what's stamped on the lock.

It sometimes works. It works the way generate-and-test works on any hard problem: at exponential cost, disguised as diligence.

Watch someone good at debugging and the approach is different. They read the symptom, and before touching anything, they state a theory of what would produce it. Then they design the smallest possible check that would prove or kill that theory.

The bug report says the button doesn't work. A bad debugger opens the button's onClick handler and starts reading. A good debugger asks a prior question: is the handler even firing? That's a five-second check — a console.log at the top of the function — and it splits the entire problem space in half before a single line of business logic gets read.

This is the actual skill. Not knowing more tools. Narrowing the search space faster than the next person, one binary question at a time.

Each question, answered, halves what's left to check. Five good questions can eliminate a codebase that would take an hour to read line by line.

The mental model underneath this is simple: a bug is a gap between what you believe the system does and what it actually does. Debugging is finding where that gap is, not staring at code until something looks wrong.

Which means the highest-leverage moment in debugging isn't when you're looking at code. It's before that — when you're forming the belief you're about to test. An engineer who can't articulate what they expect to see next isn't debugging. They're browsing.

This also explains why explaining the bug to someone else so often fixes it before they say a word. Check out rubber duck debugging.

Tools accelerate this process. They don't replace it. A debugger, a profiler, a distributed trace — every one of them answers a question faster once you know which question to ask. None of them tells you which question is worth asking first.

That's why the engineer who's fastest at debugging isn't the one with the best tooling.