Debugger fluency

Debugger fluency

A debugger freezes the program where the bug lives and lets you read every variable, frame, and expression at that instant. Many developers reach only for print statements because they never learned the handful of commands that make a debugger fast. Those commands trade an afternoon of recompiling for one inspected pause.

Method

1. Break at the fault, not at main. Set the breakpoint on the misbehaving line or the exception itself: breakpoint() in Python, a gutter dot in the IDE, or break file.py:88. Stepping from the entry point through everything wastes the tool.
2. Master the five movements. Step over (n) runs a line, step into (s) enters a call, continue (c) runs to the next stop, finish (r) returns from the frame, and up/down walk the stack. The rest is convenience.
3. Use conditional breakpoints inside loops. Stop only when it matters: break process.py:40 if user_id == 4187. Instead of hitting continue nine hundred times you land exactly on the iteration that fails.
4. Watch expressions, not just variables. Add order.total - sum(items) as a watch so the debugger re-evaluates it at every stop. The moment the invariant breaks you see it, without scanning raw fields by eye.
5. Walk the stack from the crash. On an exception, drop into a post-mortem with pdb.pm() or "break on caught exception," then move up through the callers reading locals. The bad value was often set three frames above where it blew up.
6. Mutate state live to test a fix. Reassign a variable at the prompt and continue, or evaluate the corrected expression in place. Confirm the hypothesis holds before you edit a single line of source.
7. Script the repeat with a startup file. Put recurring breakpoints and commands in a .pdbrc or a launch config so re-entering the session drops you at the scene without retyping the setup.

Signals

• Do you reach the failing state in one continue, not fifty manual steps?
• Can you name the frame where the wrong value first appears?
• Do your watch expressions encode the invariant, so a stop explains itself?

Boundaries

Where you cannot attach, a locked container, a hot production path, or a timing race a breakpoint would freeze, fall back to print-debugging or heisenbugs. A debugger inspects one run, so reproduce the failure reliably with reproduction-first before you open it.