The Debugging Mindset
Most engineers debug by guessing. The good ones don't.
Debugging is half the job. It's also the half nobody teaches. Here's the mental model that distinguishes engineers who can debug anything from engineers who can't.
Debugging is unteachable, mostly. People learn by doing. But there are mental moves you can name.
Move 1: Form a hypothesis BEFORE looking at logs
Most engineers, when faced with a bug: open the logs and start scrolling. Bad.
Good engineers: form a hypothesis first. "The bug is that X happens when Y, because Z." Then go to the data to confirm or deny.
This single move makes debugging 5x faster. You're now looking for specific signal, not browsing.
Move 2: When stuck, prove yourself wrong
When your hypothesis isn't matching the data, the temptation is to twist the hypothesis. Resist. Go back to first principles. What does the data definitely tell you? Form a different hypothesis.
The bug is almost never where you first thought it was. Engineers who are good at debugging are good at giving up on bad hypotheses fast.
Move 3: Bisect
If a bug appeared in some range of commits/configs/inputs, bisect. Don't guess. Don't assume. Bisect until you have the smallest reproducible case.
git bisect was added to git 20+ years ago. Use it.
Move 4: Read the code, not the abstraction
When the abstraction (your ORM, your framework, your library) is doing something unexpected, drop into the actual source. Most production code is in directories you can navigate. Read it.
I've solved many bugs by reading the library source code that nobody on my team had ever opened.
Move 5: Notice when you stop being curious
Debugging is mentally taxing. There's a moment when you stop being curious and start guessing. Notice it. Take a 15-minute walk. Come back fresh. The guess that took you 30 minutes will take 3 minutes when you're rested.
Move 6: Write it down
When you find the bug, write down the chain of reasoning. Future you will thank you. Future colleagues will thank you. Your post-mortems will be sharper. Your pattern recognition will compound.
What separates the great
The great engineers I've worked with treat debugging like a science. Hypothesis, evidence, conclusion, document. The mediocre engineers treat it like archaeology. Dig until you find something.
The first style scales. The second doesn't.