The “Rubber duck debugging” method
Introduction
If you are a Software engineer you have probably heard about it. Or not ?
Being taught the “Rubber duck debugging” method (or simply “rubberducking”) is one of the most vivid memories I have back from when I studied in the Computer Science school. It was in a lecture of the “Software Engineering ” course when the professor explained, what would later become a guide to solve complex programming and software architecture problems on a daily basis.
The method
“Rubber duck debugging” us based on a simple idea: In order to understand any coding problem well enough, you have to be able to explain it in simple, plain natural language to someone who has no engineering background. Someone like a Rubber duck! By explaining both the problem that tries to solve and the possible solution line-by-line, the software engineer will probably “see” many aspects that he was previously unaware of. When explaining to a rubber duck (or any other inanimate object) what the code is supposed to do and what the code actually does, the software engineer is forced to observe and note any discrepancies and thus, to be lead to the solution.
Apart from that, the process of teaching something to someone else, forces the one who teaches it to evaluate many different aspects and thus to understand it better.
According to https://rubberduckdebugging.com, an unofficial Rubber duck debugging manifesto, the steps to follow in order to solve any software engineering problem with this method are these:
1. Beg, borrow, steal, buy, fabricate or otherwise obtain a rubber duck (bathtub variety).
2. Place rubber duck on desk and inform it you are just going to go over some code with it, if that’s all right.
3. Explain to the duck what your code is supposed to do, and then go into detail and explain your code line by line.
At some point you will tell the duck what you are doing next and then realise that that is not in fact what you are actually doing. The duck will sit there serenely, happy in the knowledge that it has helped you on your way.
Of course, instead of a Rubber duck, a software engineer can apply the same method with the help of a colleague, however implementing these steps with an inanimate object will save valuable time from the colleagues.
Conclusion
I understand that applying the method exactly as mentioned above will probably seem difficult or even weird. Please, do not stick to details but try to remember and apply the core concept of the “Rubber duck debugging” method, which is that if you try to explain in a simple way the problem and the code, new aspects will become apparent and will probably help you to reach a solution faster.
If this post was helpful, please click the clap 👏 button below a few times to show your support for the author 👇
