Debugging: Debuggers, Breakpoints & a Systematic Method

Q: What is Git bisect and when is it useful?

git bisect binary-searches your commit history to find the exact commit that introduced a bug. You mark a known-good commit and a known-bad one, and Git checks out commits in between for you to test, halving the range each time until it pinpoints the culprit. It's invaluable when a bug appeared "sometime recently" but you don't know which change caused it — instead of reading every diff, you test a handful of commits (log₂ of the range). Once you find the introducing commit, its diff usually makes the cause obvious. See Git.

Debugging

Debugging is the process of finding and fixing the cause of incorrect behavior — and it's where developers spend a huge share of their time. The difference between an hour of frustration and a five-minute fix is rarely talent; it's method. Effective debugging is a disciplined, hypothesis-driven process: reproduce the bug, form a theory about the cause, test it, and narrow down — rather than randomly changing code and hoping.

The most underused tool is the debugger itself. Many developers lean entirely on print statements when stepping through execution with breakpoints — inspecting variables and the call stack live — would reveal the problem far faster. Learning to debug systematically, with the right tools, is one of the highest-return skills in software.

TL;DR

Debugging is systematic: reproduce → hypothesize → test → narrow → fix → verify.
Use a debugger (breakpoints, step-through, variable inspection) — not just print.
Read the stack trace — it usually points near the cause.
Beyond the basics: logging, profilers, Git bisect, binary search of the problem space.

Quick Example

The systematic loop beats random changes every time:

The Scientific Method of Debugging

Treat a bug as a hypothesis to test, not a mystery to stare at:

Reproduce reliably — a consistent repro is half the battle; reduce it to the smallest case.
Form a hypothesis — what specifically could cause this? Be precise.
Test the hypothesis — use a breakpoint, assertion, or log to confirm or rule it out.
Narrow down — binary-search the code path and inputs to isolate the failure point.
Fix the root cause — not just the symptom; then verify the repro is gone.
Add a regression test — so the bug can't silently return (see Test Coverage).

Debuggers & Breakpoints

A debugger lets you pause execution and inspect program state live:

Breakpoints — pause at a line; conditional breakpoints pause only when a condition holds.
Step over / into / out — walk execution line by line, into or over function calls.
Inspect — examine variable values, the call stack, and watch expressions.
Evaluate — run expressions in the paused context.

Most editors and IDEs have integrated debuggers; browsers ship powerful ones (DevTools) for frontend.

💡 Print debugging isn't wrong — it's quick and works across boundaries logs reach. But for non-trivial state, a debugger that shows you everything at the moment of failure is far faster.

Reading Stack Traces

A stack trace is the program telling you where it failed and how it got there. Read it deliberately:

The error type and message — what went wrong (NullPointerException, TypeError: x is not a function).
The top frame — usually where the error was thrown.
Your code's frames — scan past library frames to the last line of your code; that's often the real lead.

Tools Beyond the Basics

Logging — for issues you can't reproduce locally (production, intermittent). See Logging.
Profilers — for performance bugs: where is time/memory actually going? See Performance Optimization.
Git bisect — binary-search your commit history to find which change introduced a bug (see Git).
Rubber-duck debugging — explaining the problem aloud often surfaces the answer.

Best Practices

Reproduce first — you can't reliably fix what you can't trigger.
Change one thing at a time — random shotgun edits hide the real cause.
Read the error message and stack trace before diving in — they often name the problem.
Learn your debugger — breakpoints and step-through beat scattering prints.
Fix the root cause and add a test — symptom patches let the bug return.

Common Mistakes

Changing code randomly

Fixing the symptom, not the cause

FAQ

How do I debug a bug I can't reproduce?

Reproduction is the goal, so first try to make it reproducible: gather the exact inputs, environment, and steps from when it occurred, and reduce variables. When it's genuinely intermittent or production-only, lean on observability — structured logging with enough context (ids, inputs, state) to reconstruct what happened, plus error monitoring that captures stack traces and the surrounding state. Add targeted logging around the suspected area and wait for it to recur. Many "unreproducible" bugs become clear once you log the right state at the right place.

When should I use a debugger versus print statements?

Use print/log debugging for quick checks, for code paths a debugger can't easily reach (across services, in production), and when you want a persistent trace. Use a debugger for non-trivial bugs where you need to inspect rich state — step through execution, examine variables and the call stack, and test conditions live at the moment of failure. The debugger is faster and more thorough for understanding why something is wrong; many developers under-use it. Learn both, and reach for the debugger more than you probably do.

How do I read a stack trace effectively?

Start with the error type and message — they usually summarize what went wrong. The top frame is typically where the error was thrown, but the most actionable line is often the last frame in your code before it disappears into library/framework frames; that's where your logic met the problem. Read from the top, skim past third-party frames, and focus on your own files and line numbers. The trace shows both the failure point and the call path that led there, which together usually point you very close to the cause.

What is Git bisect and when is it useful?

git bisect binary-searches your commit history to find the exact commit that introduced a bug. You mark a known-good commit and a known-bad one, and Git checks out commits in between for you to test, halving the range each time until it pinpoints the culprit. It's invaluable when a bug appeared "sometime recently" but you don't know which change caused it — instead of reading every diff, you test a handful of commits (log₂ of the range). Once you find the introducing commit, its diff usually makes the cause obvious. See Git.