Did you ever get stuck while coding and asked for help from a more experienced colleague, but as you explained your code to him, you answered the questions yourself?

I have to admit it has already happened to me, and at such times I always felt discomforted that I disturbed my colleague unnecessarily. If I had stepped back a bit and read the code, I would have found the right answers on my own.

Sometimes we developers can get very immersed in coding, in which case we get into the "zone" and just write and write… but basically we hardly think about what we're doing. We only start to take a closer look at our lines when we don't understand something, when doesn't work, or when a little elf whispers in our head that "that's just not the way to do it" or "there's definitely a more elegant solution".

At such times, we have to lean back, get out of the zone, and find our old childhood friend, the good old rubber duck. A rubber duck?! Yes! It must not be a rubber duck, any object that will be our colleague for a while will do: the office dog or a plush monkey. And just as part of a peer review, we will explain to him or her what we did.

That's when those "Aha!" thoughts are born: when we are essentially code reviewing our own code. This method is not a substitute for the actual code review, because this code is like our child and like all good parents, our code will be the most beautiful and the best for us, but it does not hurt for us to look at it for a while before others do.

Code review or peer review is a software quality assurance method in which one or more persons review the partial or complete code base of a software. At least one person must be different from the author of the code.

The purpose of the code review is to improve the quality and maintainability of the code, detect software bugs, to transfer knowledge between colleagues, and to strengthen the sense of collective responsibility.

So what is this rubber duck debugging method?

• 1. Buy, borrow or steal a rubber duck from a colleague
• 2. Put your new "colleague" on your desk
• 3. If you feel like you've lost yourself in code, call for help and start explaining to him in detail why you did it.

A good piece of advice: if you work in an office with several real colleagues, you better give them a heads up.

But why does it work?

The answer to why is simple. Software development is a summary of very complex processes that are very difficult to follow after a while. When we've been very adventurous and already feel like we don't even understand what we're doing, it helps to start rethinking from the beginning what our goal was and what we've achieved so far.

There is no better method than trying to explain how the software currently works and what we want to achieve for a "colleague" who knows nothing about the software.

The project has to be explained to him in some detail, and in the process, we essentially explain it to ourselves. And what better way to do that than with a "colleague" who really knows nothing about the code (like a rubber duck)? Notice that as we explain the code line by line, the image in our own heads begins to clear up.

If you're blocked and you really don't know how to proceed, call on the good old rubber duck for help, he'll solve the problem. It' worth a shot.