Debugging Strategies
Parent: Debugging Techniques · Published reference · snapshot 2026-09-08 · skill software-engineering-patterns/references/debugging-strategies.md
↓ Facts as markdownall context files
Transform debugging from frustrating guesswork into systematic problem-solving with proven strategies, powerful tools, and methodical approaches.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Debugging Strategies
- Transform debugging from frustrating guesswork into systematic problem-solving with proven strategies, powerful tools, and methodical approaches. [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#debugging-strategies]
When to Use This Skill
- Tracking down elusive bugs [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#when-to-use-this-skill]
- Investigating performance issues [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#when-to-use-this-skill]
- Understanding unfamiliar codebases [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#when-to-use-this-skill]
- Debugging production issues [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#when-to-use-this-skill]
- Analyzing crash dumps and stack traces [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#when-to-use-this-skill]
- Profiling application performance [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#when-to-use-this-skill]
- Investigating memory leaks [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#when-to-use-this-skill]
- Debugging distributed systems [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#when-to-use-this-skill]
1. The Scientific Method
- 1. Observe: What's the actual behavior? 2. Hypothesize: What could be causing it? 3. Experiment: Test your hypothesis 4. Analyze: Did it prove/disprove your theory? 5. Repeat: Until you find the root cause [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#1-the-scientific-method]
2. Debugging Mindset
- "It can't be X" - Yes it can [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#2-debugging-mindset]
- "I didn't change Y" - Check anyway [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#2-debugging-mindset]
- "It works on my machine" - Find out why [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#2-debugging-mindset]
- Reproduce consistently [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#2-debugging-mindset]
- Take breaks when stuck [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#2-debugging-mindset]
3. Rubber Duck Debugging
- Explain your code and problem out loud (to a rubber duck, colleague, or yourself). Often reveals the issue. [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#3-rubber-duck-debugging]
JavaScript/TypeScript Debugging
- VS Code Debugger Configuration: [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#javascripttypescript-debugging]
Technique 2: Differential Debugging
- Compare working vs broken: [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#technique-2-differential-debugging]
Best Practices
- Reproduce First: Can't fix what you can't reproduce [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#best-practices]
- Isolate the Problem: Remove complexity until minimal case [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#best-practices]
- Read Error Messages: They're usually helpful [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#best-practices]
- Check Recent Changes: Most bugs are recent [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#best-practices]
- Use Version Control: Git bisect, blame, history [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#best-practices]
- Take Breaks: Fresh eyes see better [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#best-practices]
- Document Findings: Help future you [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#best-practices]
- Fix Root Cause: Not just symptoms [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#best-practices]
Common Debugging Mistakes
- Making Multiple Changes: Change one thing at a time [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#common-debugging-mistakes]
- Not Reading Error Messages: Read the full stack trace [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#common-debugging-mistakes]
- Assuming It's Complex: Often it's simple [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#common-debugging-mistakes]
- Debug Logging in Prod: Remove before shipping [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#common-debugging-mistakes]
- Not Using Debugger: console.log isn't always best [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#common-debugging-mistakes]
- Giving Up Too Soon: Persistence pays off [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#common-debugging-mistakes]
- Not Testing the Fix: Verify it actually works [archived source: https://llms-explorer.com/sources/mdb-context-hub/debugging-strategies/#common-debugging-mistakes]
Where this helps
- Tracking down an intermittent bug that only reproduces in production, where systematic hypothesis testing narrows the search space faster than guessing. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Debugging someone else's unfamiliar codebase, where rubber-duck explaining each line forces you to read what the code actually does rather than what you assume it does. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Isolating a regression introduced by a recent change, using differential debugging (bisecting between a working and a broken state) instead of guessing which commit is at fault. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Working a flaky test failure that different engineers keep dismissing as "probably a timing issue" without anyone ever confirming the actual mechanism. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
How to apply this
- Apply the scientific method explicitly: form a specific, falsifiable hypothesis about the bug's cause before changing any code, then design a test that would prove or disprove it. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Use differential debugging by bisecting between a known-good and known-bad state (a specific commit, a specific input) rather than guessing which of several recent changes caused a regression. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Practice rubber-duck debugging by explaining the code's intended behavior out loud or in writing, line by line, before reaching for a debugger — articulating it often surfaces the mismatch between intent and actual code. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Match the technique to the bug type: differential/bisection for regressions, systematic hypothesis testing for logic errors, and dedicated concurrency tools (not scattered print statements) for race conditions. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Antipatterns
- Changing multiple things at once while chasing a bug, which makes it impossible to tell which change actually fixed (or didn't fix) the problem. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Reaching for a debugger or print statements before forming any hypothesis about the cause, turning debugging into unguided exploration instead of a directed search. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Dismissing a flaky failure as "probably timing" without ever confirming the mechanism, which lets the same class of bug resurface repeatedly under a different symptom. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Adding heavy logging or breakpoints to a suspected concurrency bug without considering that the instrumentation itself can change timing and hide the very race condition being hunted (a Heisenbug). [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Known issues
- The scientific method for debugging takes real discipline under time pressure; teams under deadline stress tend to revert to guess-and-check. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Differential and bisection debugging assumes a reliably reproducible failure and a clean history of intermediate states — neither is guaranteed for flaky or environment-dependent bugs. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Rubber-duck debugging works best on logic errors you can reason through; it does little for bugs caused by external state such as race conditions, network timing, or third-party service behavior. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
- Strategies that work well for deterministic bugs often fail on concurrency bugs, where the act of adding logging or breakpoints can itself change timing and hide the bug. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Children
- Root Cause Analysis Frameworks (frontier)
- Reproduction Checklists (frontier)
- Hypothesis Formation (frontier)
- Systematic Debugging Process (frontier)
Frontier under this node: Hypothesis Formation, Reproduction Checklists, Root Cause Analysis Frameworks, Systematic Debugging Process