Lesson 4 12 min

Debugging Tools

Master essential debugging tools — IDE debuggers, browser DevTools, print debugging, and AI-enhanced workflows for inspecting code state during execution.

🔄 Recall Bridge: In the previous lesson, you learned the 5-step debugging process — reproduce, isolate, identify, fix, verify. Now let’s equip you with the tools that make each step more efficient.

Debugging tools let you observe your program’s state during execution — variable values, call stacks, network requests, and DOM changes. Choosing the right tool for each debugging scenario is a skill that dramatically reduces investigation time.

Tool 1: Print/Log Debugging

The simplest and most universal debugging technique:

Strategic print debugging (not random):

# BAD: Random prints that tell you nothing
print(data)
print("here")
print(result)

# GOOD: Labeled prints with context
print(f"[process_data] Input: {type(data)} len={len(data)}")
print(f"[process_data] After filter: {len(filtered)} items")
print(f"[process_data] Result: {result} (expected: positive)")

AI prompt for print debugging:

I’m debugging this function: [PASTE CODE]. Add strategic print/log statements that will help me trace: (1) What data enters the function, (2) How it changes at each processing step, (3) What decision branches are taken, (4) What comes out. Label each print clearly.

Tool 2: IDE Debugger (Breakpoints)

Feature	What It Does	When to Use
Breakpoint	Pauses execution at a line	Inspect state at a specific point
Conditional breakpoint	Pauses only when condition is true	“Stop when i > 100 and value < 0”
Step Over	Execute current line, stop at next	Follow execution line by line
Step Into	Jump into a function call	Trace into deeper function
Step Out	Run until current function returns	Finished inspecting, continue
Watch expression	Monitor a value continuously	Track computed values

AI prompt for breakpoint strategy:

I’m debugging [DESCRIBE BUG]. Where should I set breakpoints and what conditions should I use? My code: [PASTE].

Tool 3: Browser DevTools

Tab	Debugs	Key Features
Console	JavaScript errors, log output	Errors, warnings, interactive JS execution
Elements	HTML/CSS state, event listeners	Inspect DOM, modify styles live, view listeners
Sources	JavaScript execution	Breakpoints, step through code, watch variables
Network	API calls, resource loading	Request/response data, timing, errors
Performance	Runtime performance	Frame rate, long tasks, rendering
Application	Storage, cookies, service workers	localStorage, sessionStorage, cookies

Debugging workflow for web apps:

Symptom	Start With	Then Check
Button doesn’t work	Console (errors)	Elements (event listeners) → Sources (breakpoints)
Page loads slowly	Network (waterfall)	Performance (long tasks)
Wrong data displayed	Network (API response)	Sources (data processing logic)
Layout broken	Elements (computed styles)	Console (CSS warnings)
State not updating	Sources (breakpoints in state logic)	Application (storage)

Tool 4: AI as Debugging Partner

Rubber duck debugging with AI:

I’m stuck on a bug. Let me explain what’s happening and you help me think through it: (1) Expected behavior: [WHAT SHOULD HAPPEN], (2) Actual behavior: [WHAT ACTUALLY HAPPENS], (3) What I’ve checked so far: [LIST], (4) My current hypothesis: [WHAT I THINK IS WRONG]. Poke holes in my hypothesis. What am I missing? What else should I check?

✅ Quick Check: You set a breakpoint in a JavaScript async function. The breakpoint never triggers even though you’re sure the function is called. Why? (Answer: Common causes: (1) The source map doesn’t match the running code — rebuild your project. (2) The function is called but throws before reaching your breakpoint line. Set the breakpoint earlier, or enable “Pause on caught exceptions” in DevTools. (3) You’re debugging the wrong file — if there are multiple copies (bundled and source), the breakpoint might be in the one that’s not executing.)

When to Use Which Tool

Situation	Best Tool	Why
Quick value check	Print statement	Fastest to add, minimal context switch
Complex state inspection	IDE debugger	See all variables at once, step through
Web page behavior	Browser DevTools	Inspect DOM, network, JS together
API/network issues	Network tab / curl	See exact request and response
Production bug	Structured logging	Can’t attach debugger to production
Concurrent/async bugs	Logging with timestamps	Debuggers alter timing of async code

Key Takeaways

Strategic print debugging (labeled, contextual statements) is the most universal tool and often the most practical — works in every environment, leaves a persistent trail, and is faster than a debugger for simple checks; upgrade to a debugger when you need more than 5 prints
Browser DevTools panels map to debugging layers: Console for errors, Elements for DOM/events, Sources for code stepping, Network for API calls — using them in order systematically narrows down whether the issue is in JS, DOM, logic, or API
AI excels as a rubber duck debugging partner: explain the expected behavior, actual behavior, what you’ve checked, and your current hypothesis — AI pokes holes in your reasoning and suggests what you might be missing

Up Next

In the next lesson, you’ll learn to recognize common bug patterns — the recurring failure modes that cause 80% of bugs — so you can identify them quickly instead of debugging from scratch.

Knowledge Check

1. You're debugging a function with 5 variables changing across 20 iterations of a loop. You add 5 print statements to track each variable. The output is 100 lines of values. You can't find the pattern. What's a better approach?

Add more print statements with labels to make the output easier to read Use a debugger with breakpoints and conditional watches instead. Set a breakpoint inside the loop with a condition (e.g., 'break when iteration > 15 or when value < 0'). At the breakpoint: (1) Inspect ALL variables at once in the Variables panel — no print formatting needed. (2) Step through one iteration at a time, watching values change. (3) Add watch expressions: 'items[i].price * items[i].quantity' — see computed values without modifying code. (4) Use conditional breakpoints: 'only stop when total < 0' — skip the 15 working iterations and stop at the broken one. Debuggers let you inspect state without modifying code, which is cleaner and faster than print debugging for complex scenarios Reduce the loop to 5 iterations to simplify the output

2. You have a web page where a button click should update a counter display. Clicking does nothing. Where do you start debugging in the browser?

Open browser DevTools and start with the Console tab for errors, then the Elements tab for DOM state. Workflow: (1) Console — check for JavaScript errors (red text). An uncaught error might prevent the click handler from running. (2) Elements — right-click the button, 'Inspect'. Check if it has an event listener (Event Listeners panel). If not, the listener never attached. (3) Sources — set a breakpoint in the click handler function. Click the button. If the breakpoint doesn't trigger, the event listener is wrong. If it triggers, step through the code to see where it fails. (4) Network — if the handler calls an API, check if the request is sent and what it returns. This systematic tool-by-tool approach narrows down the problem layer by layer View the page source and look for JavaScript errors in the HTML Check if JavaScript is disabled in the browser settings

3. A senior developer on your team says: 'I almost never use a debugger — I use print/log statements for 90% of debugging.' Is this a valid approach?

No — print debugging is a beginner habit that should be replaced by proper debuggers Yes — print/log debugging is the most common technique even among experienced developers, and it's often the most practical. Reasons: (1) Works everywhere — servers, scripts, CI, production (debuggers often don't). (2) Leaves a trail — log output persists after the session, breakpoints don't. (3) Faster for quick checks — adding a print is faster than launching a debugger for simple bugs. (4) Works for concurrent/async code — debuggers struggle with async flows, but logs capture the actual execution order. The skill is knowing WHEN to upgrade: if you're adding more than 5 print statements, switch to a debugger. If you're debugging iteration-level behavior, use a debugger. If you're debugging production, use structured logging It depends on the language — some languages have better debugger support than others

Answer all questions to check

Complete the quiz above first

Related Skills

Debug Detective Systematic Debugging