8.3 — Debugging like a pro

Until now you’ve hunted bugs the way everyone starts: sprinkle console.log, re-run, squint. There’s a sharper tool, and it’s been under your fingers all phase: a debugger pauses the running program mid-flight, so you can inspect every variable at the exact moment things go wrong.

Best part: you already know its panels. The Scope panel is 3.5’s bubbles. The Call Stack panel is 3.6’s tower. Today they get their professional names — and a real bug to catch.

watch it happen

function priceAfterDiscount(price, percent) {
  const discount = price * percent;
  return price - discount;
}

const paid = priceAfterDiscount(200, 10);
console.log(paid);

The setup: a discount function. priceAfterDiscount(200, 10) should take 10% off 200 and return 180. It returns MINUS 1,800 — the shop is paying customers. Somewhere inside, a wrong number is born.

under the hood

The deeper story, with the real names for things — this part is what turns “I saw it” into “I can explain it.”

You can write a breakpoint into code: the statement debugger; pauses execution at that line whenever DevTools is open — and does nothing when it isn’t. Handy; just never commit it.

Real debuggers also offer conditional breakpoints — “pause here only when i === 97” — which is the sane way to catch a bug that appears on the 97th lap of a loop. And step out finishes the current function and pauses back at the caller: the up-elevator of the tower.

Honesty note: professionals still use console.log daily — logs are breadcrumbs, the debugger is the autopsy table. Quick look → log. Confusing state → pause.

Job note: Playwright ships this exact experience for tests — npx playwright test --debug opens an inspector where you step through your test actions the same way: pause, inspect, step. Same buttons, same tower, Phase 11 territory.

your turn

⌨️ the haunted discount machine

The starter code below PAYS the customer instead of discounting. Play debugger: find the line where the wrong number is born, fix it so percent means a human percent (10 = 10%), and prove it on two purchases.

requirements:

Run the starter first and read the wrong outputs — that’s your bug report.
Fix priceAfterDiscount so percent arriving as 10 means ten percent. Change the formula, not the calls.
The two existing prints must now show the honest prices for (200, 10) and (50, 10).

when you press RUN, the console must show exactly:

180

✏️ Quick check 1

You’re paused on a line that calls helper(). Which button pauses INSIDE helper — step over or step into?

✏️ Quick check 2

A breakpoint pauses on line 2, which reads const discount = price * percent. Has discount received its value yet? Type yes or no.

✏️ Quick check 3

Which DevTools panel is this course’s call-stack tower, drawn for real?

teach it back

🗣️ Now teach it back

Explain to a friend how you’d find a wrong-number bug with a debugger instead of console.log: what a breakpoint does, what the Scope and Call Stack panels show, and the difference between step over and step into.

Write it as if your friend is sitting next to you. Saved to your journal — future-you will use these notes to teach others.

a few sentences, minimum — you’ve got this

to remember

A breakpoint pauses the program BEFORE its line runs — the whole world frozen and inspectable. The debugger; statement does the same from inside code.

Scope panel = 3.5’s bubbles live. Call Stack panel = 3.6’s tower, clickable. Watch = a pinned expression recomputed at every pause.

Step over = run one line (hop calls whole). Step into = dive inside the call. Logs for breadcrumbs, the debugger for autopsies — Playwright’s --debug gives tests the same buttons.

next: 8.4 ES6+ grab bag: ?. and ?? →