systematic-debugging

Finding the root cause of test failures requires tracing symptoms back to the original trigger by consistently reproducing the error, analyzing data flow across component boundaries, and fixing at the source. This prevents recurring bugs from symptom-based fixes.

Debugging production incidents under time pressure requires a pressure-resistant, four-phase workflow: root cause investigation, pattern analysis, single-hypothesis minimal testing, and root-cause-only implementation. It enforces strict stop conditions to re-analyze when repeated fixes fail.

To trace data flow across multi-component systems for integration problems, add instrumentation to trace evidence across boundaries before proposing fixes. This evidence-driven debugging approach ensures you identify the true triggering cause rather than guessing at symptoms.

Fixes keep failing when you patch symptoms instead of locating the true root cause. You stop recurring bugs by enforcing a strict stop condition after repeated failures, forcing you to re-analyze the problem and trace back to the original trigger before implementing any new fix.

Yes, you can use systematic debugging for build failures and performance issues. The four-phase workflow applies to any technical failure including unexpected behavior and integration problems, requiring you to complete root-cause investigation before progressing to hypothesis testing and implementation.