systematic-debugging

Start by reading the full error message and stack trace, then reproduce the failure consistently with a command like pytest tests/test_module.py -v. Check recent git changes, trace the bad value upstream, and only propose a fix after forming a root cause hypothesis.

Root cause analysis means identifying why a bug occurs before attempting any fix, rather than patching symptoms. It involves reading errors carefully, reproducing the issue, gathering evidence at component boundaries, and tracing data flow to the source.

Stop after three failed fix attempts. If each fix reveals new problems in different places or requires massive refactoring, the pattern itself is likely flawed. Discuss the architecture with your team before attempting a fourth fix.

No. Simple bugs have root causes too, and under time pressure systematic debugging is faster than guess-and-check thrashing. Skipping investigation leads to repeated failed fixes and new bugs introduced by unverified patches.

Add diagnostic instrumentation at each component boundary: log what data enters and exits each layer, verify config propagation, and check state at every step. Run once to gather evidence showing where the failure occurs, then investigate that specific component.