# Systematic Debugging Walkthrough — Learn by Doing ## Step 1: Reproduce Before You Fix You hear "the app crashes when I click Submit." You haven't seen it yourself. **Task:** Before writing any code, what would you do? List at least 3 concrete steps to get a reliable reproduction. **Question:** Why is "it crashes sometimes" harder to debug than "it crashes when I click Submit with an empty email field"? What changes when you have a precise repro? **Checkpoint:** The user should list: get exact steps, environment (browser, data), try to reproduce themselves, capture error/logs. They understand that a reliable repro is the foundation. --- ## Step 2: Read a Stack Trace You see: ``` TypeError: items.forEach is not a function at processOrder (orderService.js:12:8) at handleCheckout (cart.js:45:22) at onClick (CheckoutButton.jsx:8:15) ``` **Task:** Interpret this stack trace. Where did the error occur? What's the likely cause? What would you check first? **Question:** Why does the top of the stack (orderService.js:12) matter more than the bottom? How does the call path help you? **Checkpoint:** The user identifies: error at `orderService.js:12`, `items` is not an array (maybe null/undefined or wrong type). They'd check what's passed to `processOrder` and where it comes from. They understand bottom = entry, top = failure. --- ## Step 3: Form a Hypothesis The bug: "Paginated list shows wrong items on page 3." You haven't looked at the code yet. **Task:** Write two possible hypotheses. For each, state (a) what you'd check, and (b) a test that would confirm or refute it. **Question:** What makes a hypothesis "testable"? Why is "maybe it's a bug" not useful? **Checkpoint:** User's hypotheses are specific (e.g., "off-by-one in page index" or "API returns wrong offset"). Their tests are concrete (inspect API response, log page index). They understand testable = can verify with a check. --- ## Step 4: Binary Search in Code You have a 200-line function. The bug appears when processing "order #1234" but not "order #1233." **Task:** Describe how you'd use binary search to isolate the problem. What would you try first? Second? **Question:** Why is binary search faster than reading line-by-line from the top? When might it not work? **Checkpoint:** User suggests: bisect by order ID range, or comment out half the function and test. They understand that halving reduces search time. They note it may not work if the bug depends on complex interaction. --- ## Step 5: Use the Debugger You're debugging a function that calculates a total. The total is wrong for a specific input. **Embed:** https://developer.chrome.com/docs/devtools/javascript/ **Task:** Describe how you'd use breakpoints to find the bug. Where would you set them? What would you inspect? What's the difference between "step over" and "step into"? **Question:** When is `console.log` enough vs when do you need a real debugger? **Checkpoint:** User would set a breakpoint in the calculation loop, inspect variables (item, total), step through. Step over = run current line without entering; step into = go inside a function call. Console.log works for simple cases; debugger for loops, async, complex state. --- ## Step 6: Distinguish Cause from Symptom The bug: "User profile page shows 'undefined' for the avatar." Someone suggests: "Just add a fallback: `avatar || 'default.png'`." **Task:** Why might that fix be addressing the symptom instead of the cause? What would you investigate before (or in addition to) adding a fallback? **Question:** When is a defensive fix (like a fallback) acceptable vs when must you fix the root cause? **Checkpoint:** User recognizes: the real bug could be that the API isn't returning the avatar, or the wrong field is read. A fallback hides the symptom; the underlying bug might cause other issues. Defensive fixes are OK for resilience; root cause should still be found and fixed when possible.