The debugging mindset
A scientific approach to finding and fixing bugs
⏱ Est. ~8 min
01 · Read
Your code will break. Every engineer's code breaks. The difference between a beginner and a pro isn't that pros write bug-free code — it's that pros know how to find and fix bugs systematically.
Debugging isn't random trial and error. It's not changing things and hoping for the best. It's the scientific method: observe, hypothesize, test, conclude.
Engineers who look like debugging wizards aren't smarter — they just follow the process instead of panicking.
💡 Picture thisDebugging is like being a detective. A crime (the bug) happens. You gather evidence (error messages, logs), form a theory (hypothesis), test it (change one thing) — and either crack the case or form a new theory. You never just grab random people and hope for the best.
02 · Step-through
The debugging process — follow these steps every time you hit a bug
1. REPRODUCE
Can you make the bug happen consistently? If it's random, look for timing or state issues. If you can't reproduce it, you can't confidently fix it. Write down the exact steps that trigger the bug.
2. ISOLATE
Where exactly is it going wrong? Narrow it down to a specific file, function, or line. Use console.log or error messages to pinpoint the location. The smaller your investigation area, the faster you'll find the problem.
3. HYPOTHESIZE
What do you think is causing it? Form a theory before changing anything. "I think the bug is because we're accessing index 0 when the array is empty." Having a theory keeps your investigation focused.
4. TEST
Change one thing to test your hypothesis. Never change multiple things at once — if you change three things and the bug goes away, you don't know which one fixed it. This discipline here saves you hours later.
5. FIX
Apply the fix based on what you learned. A good fix addresses the root cause, not just the symptom. If users crash when an array is empty, don't just hide the error — handle the empty array properly.
6. VERIFY
Does the original bug still happen? Did you break anything else? Test the fix, then test the surrounding behavior. A fix that creates a new bug doesn't count as a real fix.
03 · Read
Let's apply the process in practice. You inherit a buggy app — a visitor counter API. It crashes when users hit the /api/stats endpoint. Your job: follow the debugging process to find the bug.
04 · Terminal exercise
Step 1: REPRODUCE — read the error log to understand what went wrong. Error messages are your best friend. They usually tell you exactly what happened and where.
(This section is interactive — please enable JavaScript.)
05 · Terminal exercise
Step 2: ISOLATE — the error points to count being undefined at line 7. That value comes from getVisitorCount(). Read the code and find the function to see where it goes wrong.
(This section is interactive — please enable JavaScript.)
06 · Read
Here are the golden rules of debugging that will save you countless hours. Stick them on your screen if you need to.
Key points
- Don't change multiple things at once — you won't know what fixed it
- Read the error message — it usually tells you what went wrong and where
- Trust the error, not your assumptions about where the bug is
- Every engineer debugs. Senior engineers just do it more systematically.
07 · Fill in the blank
The first step of debugging is to consistently _____ the bug.
08 · Quiz
What's the first step of debugging?
- Reproduce the bug consistently
- Change the code and hope for the best
- Ask Claude to fix it
- Delete the file and start over
Other lessons in this chapter
⚠ The full interactive experience needs JavaScript. Please enable it and reload.
※ This is an independent Traditional Chinese teaching project — not an official Anthropic product. Claude™ is a trademark of Anthropic, PBC.