systematic-debugging

Topics in the source

• Systematic Debugging
• Overview
• The Iron Law
• When to Use
• The Four Phases
• Phase 1: Root Cause Investigation
• Phase 2: Pattern Analysis
• Phase 3: Hypothesis and Testing

Core principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure. Violating the letter of this process is violating the spirit of debugging. If you haven't completed Phase 1, you cannot propose fixes. Use for ANY technical issue: Test failures Bugs in production Unexpected behavior Performance problems Build failures Integration issues Use this ESPECIALLY when: Under time pressure (emergencies make guessing tempting) "Just one quick fix" seems obvious You've already tried multiple fixes Previous fix didn't work You don't fully understand the issue Don't skip when: Issue seems simple (simple bugs have root causes too) You're in a hurry (rushing guarantees rework) Manager wants it fixed NOW (systematic is faster than thrashing) You MUST complete each phase before proceeding to the next. BEFORE attempting ANY fix: 1. Read Error Messages Carefully Don't skip past errors or warnings They often contain the exact solution Read stack traces completely Note line numbers, file paths, error codes 2. Reproduce Consistently Can you trigger it reliably? What are the exact steps? Does it happen every time? If not reproducible → gather more data, don't guess 3. Check Recen

This is an excerpt. Refer to the complete source and its current requirements.