Debugging Like a Pro
Good debugging is a habit you can learn. We work through real broken code — a race condition, a silent type coercion, a memory leak — using breakpoints, logs and bisection, and finish by writing the test that stops each bug coming back.
The route
- 20 minRead the error, all of it
Stack traces, what the top frame actually means, and where to look first.
You board here - 20 minHypothesis, then bisect
Narrowing by halves instead of by guessing — including `git bisect`.
- 20 minBreakpoints beat print statements
Conditional breakpoints, watch expressions, and stepping without losing your place.
- 20 minLeave a test behind
Turning the reproduction into the regression test that stops it coming back.
A look at the teaching
It worked last Tuesday. Find the commit that broke it without reading any of them.
git bisect start
git bisect bad # right now
git bisect good HEAD~40 # last Tuesday
# Let git drive: it checks out a midpoint, runs your command,
# and halves the range on the exit code. Six steps, not forty.
git bisect run npm test --silent
git bisect reset
Forty commits is six questions. With `bisect run` you do not even answer them — the exit code does, while you make coffee.
Who is driving
Péter teaches the way a good colleague explains things at a whiteboard — no jargon for its own sake, and nothing hidden behind “as you can see”.
Placeholder profile