Debugging for Beginners: A Calm, Repeatable Way to Find Bugs

Everyone's code has bugs — experienced developers and AI tools included. What separates people who fix them quickly from people who flail isn't talent. It's method. Debugging is a skill, and it follows the same steps every time.

The method

1. Reproduce it

Make the bug happen on purpose. Find the exact steps: which page, which button, which data, which user. If you can't make it happen reliably, you can't tell whether you've fixed it.

Write the steps down. (How to Write a Good Bug Report.)

If it only happens sometimes, look for what's different when it does: a particular user, a specific item, a time of day, a slow network, production but not locally. (Why Does My App Work Locally but Not in Production?.)

2. Read the error

If there's an error message, read the whole thing. It usually tells you what went wrong and where — the file and line number. The first line of your own code in the stack trace is the best starting point. (How to Read an Error Message.)

Check both places errors appear:

• Browser: DevTools console and Network tab. (Browser Developer Tools for Beginners.)
• Server: your app's logs or terminal.

No error at all? Then the code is running and doing the wrong thing, which is the next step's job.

3. Locate it

Narrow down where the problem is. Think of the path data takes:

User clicks → front end → request → server → database → response → page

Check each point: Did the click handler run? Did a request go out? What did the server receive? What did the database return? What came back? The bug is between the last point that looked right and the first point that looked wrong.

4. Form a hypothesis — then test it

Make a specific guess: "The discount is null because the coupon lookup is case-sensitive, and I typed save10." Then test that one guess — try SAVE10.

Change one thing at a time. Changing five things at once means you won't know which one mattered, and you may introduce new bugs.

5. Verify the fix

Run your reproduction steps again. Then check you didn't break something nearby. Ideally, add a test that fails without the fix and passes with it, so the bug can't quietly return. (How to Write Tests With AI.)

Tools

console.log (and friends)

The simplest, most-used debugging tool: print values to see what's actually happening.

console.log("cart before discount:", cart)
console.log("coupon found:", coupon)

Label your logs, so you know which is which. Remove them when you're done. On a server, logs appear in the terminal or your host's log viewer.

Breakpoints

A breakpoint pauses the code at a line so you can inspect every variable and step through line by line. In the browser, open DevTools → Sources, find the file, and click a line number. Or add debugger; to your code. VS Code has the same for server code under Run and Debug.

Breakpoints are slower to set up than a log, but far better for "why is this value wrong?"

git bisect: when did it break?

If something worked last week and doesn't now, Git can find the exact commit that broke it with a binary search:

git bisect start
git bisect bad            # the current version is broken
git bisect good a1b2c3d   # this older commit worked
# Git checks out a middle commit. Test it, then:
git bisect good           # or: git bisect bad
# …repeat until Git names the first bad commit
git bisect reset

Even with hundreds of commits, it takes only a handful of steps. (Git and GitHub for Beginners.)

Rubber-duck debugging

Explain the problem, out loud, line by line, to someone — or something, traditionally a rubber duck. Halfway through explaining what the code should do, you often notice what it actually does. Writing the bug report has the same effect.

Debugging with an AI tool

AI coding tools are excellent debugging partners when you give them evidence and structure:

• Give it the reproduction steps, the full error, and relevant logs. Not "checkout is broken."
• Ask it to explain the cause before changing code. If the explanation doesn't hold up, the fix won't either.
• Ask it to reproduce first — ideally with a failing test.
• Let it add logging to find where values go wrong, rather than guessing a fix.
• Give it the running app. An agent that can run the code and read real output debugs far better than one reading code alone.

And watch for the fix loop: the tool tries fix after fix, each one plausible, none working. After two or three failed attempts, stop, /clear the conversation, and restart with what you've learned — or step back and question your assumptions. (Stuck in an AI Fix Loop?.)

Habits that prevent long debugging sessions

• Commit working states often, so you can compare and go back.
• Make small changes and test as you go.
• Read error messages first, before reaching for fixes.
• Take a break. A surprising number of bugs are solved on a walk.

---

EasySpawn gives Claude Code the running app, its logs, and its database in one persistent workspace — so it can reproduce, add logging, and verify a fix instead of guessing from code alone. See how it works or join the waitlist.

Related: How to Read an Error Message · HTTP Status Codes Explained · How to Write a Good Bug Report