In software engineering, rubber duck debugging is a method of debugging code by articulating a problem in spoken or written natural language. The name is a reference to a story in the book The Pragmatic Programmer in which a programmer would carry around a rubber duck and debug their code by forcing themselves to explain it, line-by-line, to the duck. Many other terms exist for this technique, often involving different (usually) inanimate objects, or pets such as a dog or a cat.
Two programmers Andy Hunt and David Thomas wrote a book called The Pragmatic Programmer. Together they introduced the term rubber duck debugging as one of the methods of debugging code. Rubber duck is not some new idea or a groundbreaking debug method. Rather, it’s something that everyone was already doing, but didn’t have a name for it. Even before rubber duck came into the picture, we would talk to ourselves, friends and people around us. There are all sorts of variations. Many programmers have had the experience of explaining a problem to someone else, possibly even to someone who knows nothing about programming, and then hitting upon the solution in the process of explaining the problem. The Pragmatic Programmer touches on cognitive science behind this phenomenon. What is interesting is that when you think a thought to yourself and have that little voice in your head, that’s one thing that uses only one set of neural pathways and one set of neural processes. If instead you actually say it out loud, that activates entirely different regions of the brain, taking a totally different route.
Speaking to a rubber duck that knows nothing about coding sounds simple, but we often take for granted what we can achieve by explicitly stating things to another person when we code by ourselves. By verbalizing your assumptions, you may immediately gain new insight into the problem. In describing what the code is supposed to do and observing what it actually does, any incongruity between these two becomes apparent. More generally, teaching a subject forces its evaluation from different perspectives and can provide a deeper understanding. By using an inanimate object, the programmer can try to accomplish this without having to interrupt anyone else.