systematic-debugging

Follow the four phases: first investigate the root cause by reading errors fully, reproducing consistently, and checking recent changes. Then analyze patterns against working examples, form a single hypothesis, test it minimally, and implement one verified fix with a failing test case.

Trace backward through the call chain from the immediate cause to the original trigger, asking what called each level and what value was passed. Add stack trace instrumentation with console.error before the failing operation, and fix at the source rather than where the error appears.

Replace arbitrary setTimeout or sleep delays with condition-based waiting that polls for the actual condition you care about, such as an event appearing or state changing. Poll every 10ms with a clear timeout, which eliminates race conditions and typically speeds up test execution.

No. Systematic debugging is faster than guess-and-check thrashing even under time pressure, because random fixes mask symptoms and create new bugs. The process scales to the issue: simple bugs move through the phases quickly.

Stop attempting more fixes and question the architecture. Repeated failures where each fix reveals new problems elsewhere indicate a fundamentally wrong pattern, so discuss architectural refactoring with your team instead of attempting a fourth fix.

Only when testing actual timing behavior like debounce intervals, and only after first waiting for the triggering condition. The timeout must be based on known timing rather than guessing, with a comment documenting why it is needed.