systematic-debugging

Start with root cause investigation: read the full error and stack trace, reproduce the failure consistently, and check recent changes with git diff. Then form one specific hypothesis, test it with the smallest possible change, and verify with a failing test case before implementing the fix.

Add diagnostic instrumentation at each component boundary, logging what data enters and exits every layer. Run once to gather evidence showing 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 in a different place or requires massive refactoring, the pattern itself is likely wrong. Discuss the architecture with your team before attempting a fourth fix.

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

Quick patches treat symptoms rather than root causes, so the underlying issue persists and resurfaces elsewhere. Bundling multiple changes at once also makes it impossible to isolate what worked, frequently introducing new defects.