This is a pair-blog article with Lena Pejgan Wiberg. Her idea is that two people write a post about an agreed topic at the same time and promote each other's article. In this article, it is about "rubberducking".
Lena's blog post can be found here on her blog.
Rubberducking or "rubber duck debugging" is a debugging practice for source code and general implementation ideas.
It can also be extended to any other activity in the software development lifecycle in which the person carrying out this activity is stuck or faces impediments in any way.
The general idea is that the person having the problem tries to explain - in simple terms and in a very structured way - how the erroneous source code works and/or what the concrete problem is that needs to be solved.
While thinking about these things and telling it to someone (or something as we will see), the brain is more open to finding the solution.
Typically, rubberducking is associated with communicating your problem to an inanimate object such as, well, a rubber duck. It can in fact be any object you are drawn to - a plush animal, a stone, a picture of someone, even an imaginary thing. The reason for this is that you can use this practice without disturbing one of your co-workers.
Often times, this can be enough to find a solution yourself.
Personally, I never used this technique with a rubber duck but always with a real person. The main reason is that it would look and sound very strange when I am at our open-plan office...
There are some important things to consider, though, which we will go through below.
The person you talk to needs to be in a listening mood
That does not mean they have to keep completely silent, though. Some simple questions can actually trigger looking at the problem from another angle and getting closer to a solution!
The person needs to be up for it
It can be quite boring to listen to a thorough explanation of source code. You should ask nicely if they have time to help you first and also explain the employed rubber ducking techniques in case they don't know it yet. Otherwise, this whole process might feel weird.
The person should be unrelated to your task
Even though it is tempting to talk to colleagues in the same field, it might happen that you end up with two people scratching their heads in the end. The reason is that there is a certain bias.
Common knowledge about an area of work or a used technology can actually be a hindrance to the process and prevent you from finding a simple solution.
There are, in fact, also other ways of rubberducking - without any talking at all.
Even though the verbal way can be quicker simply because you stay in the flow of regular conversation, it is also possible via chat.
When you write about a problem, you think about it in an organized way as well, forcing your brain into a state of flow.
That's why it can be a perfectly valid way to find a simpler solution while just documenting what you have done so far. Seeing your current effort in writing often times shows clearly what is wrong with it.
The same effect can be seen sometimes when posting a question on StackOverflow or comparable forums. When you are ready to press "send", the question is already obsolete and the solution just reveals itself to you.
I firmly believe in this approach, which admittedly takes some getting used to. Again and again I came across ideas and solutions that I either found myself or that were a result of comments and inquiries from colleagues. I have found that sometimes I just think in way too complex ways. Instead of finding obvious solutions, I get lost in a particular technology, an algorithm or a design pattern.
In these cases, rubberducking helps me immensely to organize my thoughts and see the bigger picture.
You should always keep in mind that there is no shame in admitting that you are stuck right now.
Instead of wasting time frantically trying to find a solution all by yourself, why not ask a duck instead!