Debug Code Systematically

Structures debugging as a four-phase scientific-method process: reproduce (build a minimal, consistently reproducible case and document exact steps), gather information (error messages and full stack traces, environment and dependency versions, recent git history and deployment changes, and the scope of who or what is affected), form a hypothesis (what changed, what differs between working and broken states, where the failure could originate), and test and verify (binary search by commenting out half the code, strategic logging, isolating components with mocks, and diffing working versus broken configurations). Documents language-specific tooling: JavaScript and TypeScript (Chrome DevTools debugger and conditional breakpoints, console.table, console.time, console.trace, console.assert, the Performance API, and a VS Code launch.json for debugging both a program and a Jest run), Python (pdb.set_trace, the breakpoint() builtin, post-mortem debugging with pdb.post_mortem, ipdb, logging-based debugging, and cProfile with pstats for performance), and Go (the Delve debugger, debug.PrintStack for panic recovery, and CPU and memory profiling via net/http/pprof and runtime/pprof). Adds four advanced techniques - binary-search debugging via git bisect, differential debugging via a working-versus-broken comparison table, trace debugging via a method decorator that logs call arguments and return values, and memory-leak detection via heap snapshots and a before/after heapUsed diff in tests - plus issue-type playbooks for intermittent bugs (race conditions, timing dependencies, stress testing), performance issues (profile first, common culprits like N+1 queries and synchronous I/O, and named tools), and production bugs (evidence gathering via error trackers like Sentry, safe local reproduction with anonymized data, and investigating without touching production). Closes with a debugging mindset section - don't assume "it can't be X" or "it works on my machine"; reproduce, isolate, document, question, take breaks - rubber-duck debugging, common mistakes to avoid, and a quick-reference checklist covering typos, null and undefined values, off-by-one errors, async race conditions, scope issues, type mismatches, and stale caches.

Use it when tracking down elusive bugs, investigating performance issues, debugging production incidents, analyzing crash dumps or stack traces, or debugging distributed systems. Skip it when there's no reproducible issue or observable symptom, the task is purely feature development, or logs, traces, or runtime signals aren't accessible.

Input is an observed symptom - an error, a crash, a performance regression, a flaky test - and whatever logs or traces are available; output is a systematic investigation path: a hypothesis, a narrowing technique, and the matching language-specific tool or command, plus documented findings and a verified fix.

Language and platform tooling: Chrome DevTools and VS Code for JavaScript and TypeScript, pdb, ipdb, and cProfile for Python, Delve and pprof for Go, and git bisect for regression hunting. Names external tools for production and performance work: error trackers Sentry and Bugsnag, and profilers Lighthouse, clinic.js, 0x, and line_profiler.

Engineers debugging an elusive, intermittent, or production-only issue who need a methodical process and concrete per-language tooling rather than trial-and-error console.log debugging.