systematic-debugginglisted

# Systematic Debugging Random fixes waste time and add new bugs. A quick patch hides the real problem, and it comes back. **Core rule: find the root cause before you touch a fix.** A change that makes the symptom go away without explaining why it happened is not a fix. ## The Iron Law ``` NO FIX WITHOUT A ROOT-CAUSE INVESTIGATION FIRST ``` If you have not finished Phase 1, you do not get to propose a fix. This holds even when the bug looks trivial, even under time pressure, even when someone wants it fixed right now. Systematic is faster than guess-and-check. ## When to Use Any technical issue: test failures, production bugs, unexpected behaviour, performance problems, build failures, flaky tests, integration issues. Reach for it hardest when the pull toward guessing is strongest: - Under time pressure (an emergency makes guessing tempting). - "One quick fix" looks obvious. - You have already tried a fix or two and they did not hold. - A previous fix did not work. - You do not fully understand what is going on. Do not skip it because the issue "seems simple" (simple bugs have root causes too) or because you are in a hurry (rushing guarantees rework). ## The Four Phases Finish each phase before you move to the next. ### Phase 1: Find the root cause Before attempting any fix: 1. **Read the error carefully.** Do not skip past errors or warnings; they often hold the answer. Read the whole stack trace. Note line numbers, file paths, error codes. 2. **Reproduce it.**