Thinking of the term Rubber Duck brings my mind to two things, Ernie from Sesame Street singing in the bath and the USB Rubber Ducky that looks like a regular USB pen drive but does a lot more. So what’s Rubber Duck Debugging and does it involve singing in the bath?
When writing code for my personal projects I am generally working on own. The code may (or may not) be shared via my GitHub, but its mostly me that sees it and me that writes it. You may be asking, “is that a problem?” and most of the time its not but sharing the thinking behind code with others can help refactor the code. Discussing the problem the code is solving, why certain patterns or designs were chosen or what lines of code are doing helps your brain to see the code from a different perspective, which may open up different ways of doing something.
Imagine explaining the code out loud and hearing yourself repeat the same response / aim more than once, it may allow you to see that parts of your code break the DRY principle or are not needed.
It helps even more when hitting a problem (e.g., getting an error or an unexpected result) as discussing the lines of code out loud and explaining what each line should be doing can make the solution become more apparent.
So where does the rubber duck come in? Not everyone has someone to discuss coding with, so (according to The Pragmatic Programmer) some people decide to talk to a rubber duck. It doesn’t have to be a rubber duck but that’s the terminology, so even if you talk the code through with your pet cat it’s still rubber ducking.