Lesson 8 15 min

Your Debugging Playbook

Build your personal debugging playbook — combine the 5-step process, bug patterns, tools, and AI prompts into a reusable system for solving any bug efficiently.

🔄 Recall Bridge: Over the past 7 lessons, you’ve learned the debugging mindset, error message reading, the 5-step process, debugging tools, bug patterns, production debugging, and root cause analysis. Now let’s combine everything into your personal debugging playbook.

A debugging playbook is your systematic approach to any bug — a decision tree built from everything you’ve learned. Instead of starting from scratch each time, you follow a proven process that gets faster with every bug you solve.

Your Complete Debugging Playbook

Phase 1: Triage (2 minutes)

Before investigating, assess the situation:

Question	Action Based on Answer
Is production affected RIGHT NOW?	Yes → symptom fix first, root cause later
Can I reproduce it?	No → gather more context (user environment, logs, timing)
Have I seen this pattern before?	Yes → jump to the matching bug pattern
Is the error message clear?	Yes → follow the error directly to the source

Phase 2: Investigate (5-30 minutes)

Step	Action	Tool
1. Read the error	Extract type, description, location, data state	Error message anatomy (Lesson 2)
2. Reproduce	Find the exact trigger conditions	Reproduction checklist (Lesson 3)
3. Pattern match	Match symptoms to known bug patterns	Bug pattern library (Lesson 5)
4. Isolate	Binary search to find exact failure point	Binary search debugging (Lesson 3)
5. Identify	Understand WHY the code fails	Debugger or strategic logging (Lesson 4)

Phase 3: Fix (15-60 minutes)

Action	Check
Write failing test first	Test fails with current code?
Fix the root cause	Does the 5 Whys analysis point here?
Run the test	Test passes with fix?
Run full test suite	Nothing else broke?
Add prevention	Monitoring, linting rule, or documentation?

Bug Pattern Quick Reference

Use this table when you encounter a bug — match the symptoms to find the likely pattern:

Symptom	Likely Pattern	First Check
“Cannot read property of null/undefined”	Null reference	Trace backward to find where the value became null
Index out of bounds / missing last element	Off-by-one	Check loop boundaries: `<` vs `<=`, 0 vs 1
Works locally, fails in production intermittently	Race condition	Check async operation ordering, add `Promise.all()`
Returns `[object Promise]`	Missing await	Find the async call without `await`
`"5" + 3 = "53"`	Type mismatch	Check type coercion, use strict equality `===`
Value changed “mysteriously”	State mutation	Check if objects/arrays are mutated instead of copied
Works fine, then breaks after deploy	Regression	Use `git bisect` to find the breaking commit
Fails only with specific input	Edge case	Test empty strings, 0, null, special characters

AI Debugging Prompts Library

When you’re stuck (general):

I’ve been debugging for [TIME] and I’m stuck. Bug: [DESCRIBE]. What I’ve tried: [LIST]. My assumptions: [LIST]. Challenge my assumptions — which one is most likely wrong? Suggest 3 hypotheses I haven’t considered.

When you need pattern matching:

My bug has these symptoms: [LIST SYMPTOMS]. Which common bug pattern does this match: off-by-one, null reference, race condition, async error, type mismatch, state mutation, stale closure? Explain why and suggest the first thing to check.

When you need root cause analysis:

The immediate cause of my bug is [CAUSE]. Help me do a 5 Whys analysis to find the root cause. After each “why,” suggest what evidence I should look for. Stop when we reach a process or design fix.

When you need a fix reviewed:

Here’s my bug fix: [PASTE DIFF]. The bug was: [DESCRIBE]. Review my fix: (1) Does it address the root cause or just the symptom? (2) Could it break anything else? (3) What test should I write to prevent regression? (4) Is there a simpler fix?

Self-Assessment: Debugging Skills

Rate yourself honestly on each skill (1 = beginner, 5 = confident):

Skill	Key Question
Error message reading	Can I extract type, cause, location, and data state from any error?
Systematic reproduction	Can I find exact trigger conditions for intermittent bugs?
Binary search debugging	Do I halve the problem space with each test?
Bug pattern recognition	Can I match symptoms to common patterns in under 30 seconds?
Tool selection	Do I choose the right tool (print, debugger, DevTools) for each situation?
Production debugging	Can I diagnose bugs using only logs and error tracking?
Root cause analysis	Do I fix root causes or just symptoms?

Your weakest skill is your best learning opportunity. Focus practice there.

Common Debugging Mistakes

Mistake	Why It Hurts	Better Approach
Fixing without reproducing	Can’t verify the fix works	Always reproduce first
Changing multiple things at once	Can’t tell which change fixed it	One change per test
Assuming “it works on my machine”	Ignoring environment differences	Match the failing environment
Skipping the test	Bug returns weeks later	Write the regression test before fixing
Stopping at the symptom fix	Bug returns in a different form	Do the 5 Whys to find the root cause
Debugging alone for hours	Tunnel vision on wrong hypothesis	After 30 minutes stuck, get a fresh perspective
Not documenting what you tried	Repeat failed approaches after a break	Keep a debugging log during investigation

30-Day Debugging Practice Plan

Week	Focus	Practice
Week 1	Error messages	For every error you see, extract all 5 pieces (type, cause, location, data state, root question) BEFORE googling
Week 2	Systematic process	Use the 5-step process (reproduce → isolate → identify → fix → verify) on every bug, even simple ones
Week 3	Pattern recognition	When you find a bug, name the pattern before fixing it. Keep a log of which patterns you see most
Week 4	Root cause analysis	For every bug fix, ask “why” at least 3 times. Document one root cause analysis fully using the 5 Whys

Key Takeaways

Your debugging playbook is a three-phase system: triage (2 minutes — assess severity and check patterns), investigate (5-30 minutes — read error, reproduce, pattern match, isolate, identify), and fix (15-60 minutes — write failing test, fix root cause, verify, add prevention)
Pattern recognition is the highest-leverage debugging skill: matching symptoms to known bug patterns (null reference, off-by-one, race condition, type mismatch, state mutation) turns 30-minute investigations into 30-second diagnoses — build your pattern library by naming every bug you fix
The debugging meta-skill is knowing when to change approach: if you’ve been stuck for 30+ minutes, document what you’ve tried, challenge your assumptions (one of them is probably wrong), get fresh perspective from AI or a colleague, and take a break — persistence on the wrong path is not productive debugging

Course Complete

Congratulations — you now have a complete debugging toolkit. From reading error messages to root cause analysis, you can approach any bug systematically. The key is practice: use the playbook on every bug, even small ones, until the process becomes automatic. Happy debugging.

Knowledge Check

1. You encounter a bug you've never seen before. Your app shows correct data on page load but after 30 seconds, some numbers change to wrong values. No user interaction triggers it. How do you approach this using your debugging playbook?

Refresh the page and see if it happens again — it might be a one-time glitch Follow the systematic process: (1) REPRODUCE: Load the page, wait 30 seconds, confirm wrong values appear. Is it always 30 seconds? Always the same numbers? (2) PATTERN MATCH: 'Values change without user interaction after a delay' — this matches two patterns: a timer/interval updating data, or a background API polling with stale or wrong data. (3) ISOLATE: Open Network tab in DevTools. Watch for API calls around the 30-second mark. If a request fires, inspect the response — is the data wrong from the server, or does the client process it incorrectly? (4) IDENTIFY: If the API returns correct data but the display is wrong, the bug is in client-side data processing. If the API returns wrong data, the bug is server-side. (5) ROOT CAUSE: Why does the 30-second refresh return different data than the initial load? Different query? Different cache? Different user session state? (6) FIX + VERIFY: Fix the root cause, add a test, confirm the page stays correct past 30 seconds Search Stack Overflow for 'data changes after 30 seconds' to find someone with the same issue

2. You've been debugging for 2 hours and you're stuck. You've tried 8 different hypotheses and none of them were correct. What does your playbook say to do?

Keep trying — persistence is the key to debugging Take a break and come back fresh. But BEFORE you step away, do three things: (1) DOCUMENT what you've tried: write down all 8 hypotheses and why each was eliminated. This prevents re-testing the same things after the break. (2) EXPLAIN it to AI: paste your code, describe the bug, list what you've eliminated, and ask for hypotheses you haven't considered. Fresh perspective (even from AI) often catches blind spots. (3) QUESTION your assumptions: you've assumed certain things are working correctly. List those assumptions. One of them is probably wrong — the bug is hiding behind an assumption you haven't tested. After the break: start by testing your assumptions, not generating new hypotheses. The most common reason for being stuck: the bug is in a place you assumed was correct Ask a coworker to look at it — a second pair of eyes always helps

3. Your team has fixed 12 bugs this month. You notice that 5 of them were null reference errors in API response handling. What should you do beyond fixing each individual bug?

Nothing extra — each bug was fixed individually, and the specific issues are resolved Add a null check helper function that the team can use for all API responses Conduct a pattern analysis and implement systemic prevention. Five null reference bugs in API response handling reveals a CATEGORY of bug, not 5 individual bugs. Steps: (1) ANALYZE: Why do API responses have null fields? Missing validation? Schema mismatch? (2) SYSTEMIC FIX: Add response validation at the API client layer — validate response shape BEFORE passing to business logic. This catches ALL null field issues, not just the 5 you found. (3) PREVENT: Add TypeScript types or runtime schema validation (Zod, Joi) for API responses. (4) DETECT: Add monitoring for API responses with unexpected null fields. (5) DOCUMENT: Add to team debugging runbook: 'When you see null reference errors, check API response validation first.' This turns 5 bug fixes into a permanent category elimination

Answer all questions to check

Complete the quiz above first