Soft Skills & Ecosystem Deep Dive · 6 of 12

Debugging Mindset — The Quiet Superpower

Brilliant debuggers aren't faster typists; they're disciplined thinkers. They form hypotheses, change one variable at a time, read the actual error, and trust evidence over intuition. The bug doesn't care about your deadline — calm, methodical investigation always beats panicked guessing.

Hypothesis-firstBisectionRead the errorRubber duckReproduce
← Back to Soft Skills & Ecosystem
The Loop

How a Senior Debugs

Reproduce reliably
Read the actual error
Form a hypothesis
Test one variable
Confirm or revise
Fix → root-cause note

Skipping any step is how you waste an afternoon. Especially the first one.

Techniques

The Working Toolkit

  • Reproduce minimally. Smallest input that triggers the bug. Half the bugs solve themselves once you reproduce them in isolation.
  • Bisection. "When did this break?" → git bisect. "Which input causes it?" → binary-search the data.
  • Read the actual error. The first stack frame and the last line are usually the answer. People skip-read and miss it.
  • Print is fine. A well-placed log line beats an hour with a debugger you barely know.
  • Debugger when state is the problem. Step through; inspect; conditional breakpoints.
  • Diff against working. What's different between the broken case and the last known good?
  • Rubber duck. Explaining out loud surfaces the assumption you didn't know you were making.
Failure Modes

Why Debugging Stalls

  • Changing two things at once. Now you don't know which fix worked.
  • Believing it must be the framework. 99% of the time, it's your code.
  • Trusting the comment. Comments lie. The code is the truth.
  • Assuming the logs are right. Sometimes the logger itself is broken.
  • Heisenbugs. Bugs that disappear when observed — usually a race or timing issue. Add logging, don't remove it.
  • Confirmation bias. You stop looking when you've found a cause; not the cause.
After the Fix

Compound the Lesson

  • Write the failing test first. Then make it pass with the fix. Now it can't regress.
  • Note the root cause in the PR or commit message — future you will thank current you.
  • Ask "what made this hard to find?" Better logs, better tests, better assertions next time.
  • Look for siblings. The same bug pattern often hides elsewhere in the codebase.
  • Five Whys on serious incidents — the surface symptom is rarely the cause.
Tradeoffs

Pitfalls

  • Sunk-cost debugging. If you've spent two days, sometimes the right move is to revert and start clean.
  • Asking too late. A 20-minute "what am I missing?" with a colleague beats a 4-hour solo descent.
  • "Works on my machine" theatre. Reproduce in the broken environment, not yours.
  • Tired debugging. After 90 minutes of staring, sleep on it. Mornings find bugs evenings can't.
Continue

Other Soft Skills