The scientific debugging loop

Debugging is not staring at code until inspiration hits. It is a loop: observe a concrete failure, form a falsifiable hypothesis, run an experiment that could disprove it, narrow the search space, repeat. Experts feel fast because they run that loop deliberately and write things down.

The goal is the root cause — the underlying defect — not the first symptom that went red. Fixing symptoms without understanding cause is how the same pager returns next week.

Walking through the loop

Rules that keep you honest (echoed in David Agans' Debugging and Julia Evans' writing):

1. Make it fail. If it is intermittent, invest in a reliable repro before theorizing.
2. Quit thinking and look. Read the actual error, stack, metrics — do not invent a story first.
3. Change one thing at a time. Otherwise you cannot tell what mattered.
4. Keep an audit trail. Notes beat memory after hour two.
5. If you did not fix it, it is not fixed. Confirm the original failure is gone; do not declare victory on a different symptom.

Narrate the loop in standups and incidents: current hypothesis, next experiment, what would falsify it. That communication is as valuable as the fix. Managers notice who brings order to chaos. You do not need to be the hero who already knew the root cause; you need an investigation that can be followed and verified.

When you help someone, do not steal the keyboard immediately. Ask what they have tried, what the current hypothesis is, and what experiment is next. Pair on the method, not only the answer.

Debuggers, profilers and trace UIs are multipliers only after the hypothesis is clear. Jumping into a debugger "to look around" can become expensive wandering. Decide what variable you need to observe, then pick the tool that shows it fastest — sometimes that is still structured logging with a request id.

Common mistakes

• "Something with auth." Not a killable claim.
• Changing three flags at once. You cannot tell what mattered.
• Victory on a different symptom. Confirm the original failure is gone.

Check yourself

1. Rewrite "something with auth" as a hypothesis.

"The null is because user is missing when the session is anonymous" — a sentence an experiment can kill.

2. Why change one variable per experiment?

Otherwise you cannot tell which change mattered.

Key takeaways

• Observe → hypothesize → experiment → narrow; write hypotheses down.
• Look at the evidence before you invent a story.
• Confirm the original failure is gone before you call it fixed.

Further learning

A debugging manifesto (Julia Evans)A debugging manifestoJulia Evans Debugging: The 9 Indispensable Rules (David Agans)Debugging Rules! – Find out what's wrong with anything, fast.debuggingrules.com

Next: reproduce and minimize.