systematic-debugging

Follow four phases: investigate the root cause by reading errors and reproducing the issue, analyze patterns by comparing working and broken code, form and test a single hypothesis minimally, then implement one fix with a failing test. Never propose fixes before completing the investigation phase.

Add diagnostic logging at each component boundary, recording what data enters and exits every layer. Run the system once to gather evidence showing exactly where the failure occurs, then investigate only that specific component instead of guessing across the whole stack.

Stop after three failed fix attempts. If each fix reveals a new problem elsewhere, requires massive refactoring, or creates new symptoms, the pattern itself is likely flawed. Discuss the architecture with your team before attempting a fourth fix.

Yes, the process applies to every technical issue regardless of perceived simplicity or urgency. Simple bugs have root causes too, and systematic investigation is faster than guess-and-check thrashing, especially under time pressure.

Quick patches treat symptoms rather than causes, so the underlying issue resurfaces and the patch often introduces new bugs. Data from debugging sessions shows systematic approaches achieve roughly 95% first-time fix rates versus 40% for random fixes.