rubber duck debugging

programming

Debugging by explaining your code, line by line, to an inanimate object.

Popularized by "The Pragmatic Programmer", the trick works because articulating the problem out loud forces you to make your assumptions explicit, and the wrong one usually surfaces mid-sentence. The duck is optional; the explaining is the point.

Rubber duck debugging is explaining your problem, line by line, to an inanimate object, and the reason it works is not mystical. Articulating a system forces you to convert a vague internal model into explicit sequential statements, and the gaps you have been skipping over become audible the moment you have to say them out loud.

The name comes from The Pragmatic Programmer, where a programmer carried a duck and talked to it. The object is irrelevant and that is the point: a colleague works too, at the cost of their time, which is why experienced engineers apologise mid-sentence and walk away having answered themselves. The listener contributes nothing and is essential anyway.

The version worth internalizing is that this is an argument for writing. A bug report you write carefully often solves itself before you submit it, and a design document forces the same explicitness the duck does, at greater length and with a record. If you find yourself repeatedly solving problems the instant you start describing them, the lesson is not that ducks are magic. It is that your model was never as complete as it felt.

Also known as: rubber ducking, rubberduck, rubber-duck

← All glossary entries