systematic-debugging

Topics in the source

• Systematic Debugging
• The Iron Law
• When to use
• Phase 1: Root cause investigation
• Phase 2: Pattern analysis
• Phase 3: Hypothesis and testing
• Phase 4: Implementation
• After three failed fixes: question the design

Guessing at fixes feels fast and is slow. Each guess that half-works hides the real cause a little deeper, and the third patch usually breaks something the first one touched. This skill makes you find out why before you change anything. If you have not finished Phase 1, you cannot propose a fix. Not a "quick one to try", not "while we investigate". Suggesting a fix in your reply counts as proposing one. The process scales. For a simple bug the four phases take a minute: read the error, confirm the cause, write the failing check, fix it. You never skip them, you just move through them quickly. Any technical problem: test failures, production bugs, unexpected behavior, performance regressions, build or CI failures, integration issues, flaky tests. Use it especially when: There is time pressure (emergencies make guessing tempting) One quick fix looks obvious You or someone else already tried a fix that did not work You do not fully understand the issue Before attempting ANY fix: 1. Read the error completely. The whole message and stack trace, not the first line. Note file paths, line numbers and error codes. Errors often state the exact problem. 2. Reproduce it. Find the exact steps o

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