Debugging with rubber ducks and logs: a solo developer's toolkit

Pair debugging is a luxury of teams. Solo, I've had to build a toolkit that does what a good partner does: forces me to state assumptions, narrows the search space, and notices what I'm glossing over.

The toolkit

The duck, properly used. Not a meme — a discipline. Before touching code, I explain the bug aloud: what I expect, what happens, what I've tried. Half the time, the answer appears mid-sentence, because speaking forces linear thinking and bugs hide in skipped steps.

Structured logging over sprinkled prints. Log with intention: operation, key inputs, outcome. When something breaks, the story is already written. When it's really broken, the log shows the last moment the world was sane.

Bisection, everywhere. Is it in the new code or the old? Frontend or backend? This query or that one? Halve the problem space, repeatedly, until the culprit has nowhere to hide. It's the fastest algorithm in debugging and the most underused.

The one-change rule. Change one thing at a time, or the lesson from the fix is lost.

The mindset

Bugs are puzzles with a guarantee: the system is not lying. If my mental model and the observed behaviour disagree, the model is wrong. That sentence, taken seriously, is most of debugging.