All Rubber Ducks don’t look alike
My take on rubber ducking (yes people do use it as a verb!) and conversely being rubber ducked
The usage of a rubber duck to solve problems is nothing new. From mundane non-technical use of keeping a baby (or adult at times) busy and distracted in a bath tub to solving highly complex engineering problems the rubber duck is a formidable creature that has advanced our modern civilisation. That is if as a software engineer I do believe we have changed the course of humanity.
For me approaching the rubber duck is a choice rather than a force of habit. I have an incrementally escalating approach to debugging hard code, where the rubber duck is at the apex. In other words, it’s an escalation of madness where at the very end, it dissolves into blabbering about every single idiotic line of code appearing in the screen to an inanimate object.
Strange though, my rubber duck is not a duck at all. It is an android plush toy I got when buying a huge number of KitKat bars at some point. One can rubber duck anything. The rubber duck could be a plush toy, a detailed question you are typing down that requires solving or simply talking to another colleague.
Rubber ducking colleagues is fun, because they in turn tend to rubber duck you. I have found simply discussing complex design issues\ coding with a human being on the other end and trying to explain them the scenario really helps in suddenly realising a solution. Although I would advice not to leave your colleague high and dry.
There is nothing that irritates me more when being rubber ducked than to be left without an explanation of the solution that just occurred. I never mind being rubber ducked as it gives me an opportunity to learn something new. It is an easy way to find and index the “don’t do”s and problem to solution mapping.
At first I never realised rubber ducking was happening when talking to colleagues. Even when I am talking to inanimate objects there is a tendency to move in and loose focus of the outliers that might be causing the issue. Talking to a colleague on the other hand, who you know is listening to what your saying and perhaps forming opinions changes the ball game. It forces you to look at the slightly bigger picture than just the particular lines of codes that is giving trouble.
However, I would advice you chose a very skilled colleagued in the art of coding and listening to be a rubber duck. It is very important that the person be open and not take being rubber ducked as an indication of begging for a solution. Coz thats the fine line when it comes to rubber ducking people. On one hand, yes, you are asking for help. However you are not per se looking for your colleague to solve your problem. It would be quite awful if people start to think your simply asking others to solve problems that is up-to you to solve.
Even when being rubber ducked, your walking that fine line. You can of course throw the odd “Have you checked these?” questions, but essentially unless asked one should not take over solving the issue. That would put your colleague in an awkward position.
All in all rubber ducking is a powerful technique. A technique one should master. However, it should not be and never be your first instinct to pursue. The best of us of course would say “we don’t need any rubber duck. No issue is unsolvable and does not require method”, but I say to them, perhaps your rubber ducking unknowingly. As I said, rubber ducking is an easy way to get one to think step by step about the problem at hand. This is simply an aid, by forcing you to explain this problem to someone(thing), it’s a possibility that one might find the devil in the detail. Even I don’t straight away go for rubber ducking. Problem investigation is not taking a machine gun and shooting indiscriminately hoping one bullet out of hundreds would hit the target. It is a methodology where one must treat debugging like a science experiment. Starting with an investigation, forming a hypothesis and then gunning the debuggers\watchers and what not to disapprove or prove your theory. It’s also about gathering evidence and sorting through them to figure out what the issue could be.
Yes! Yes! I know. You must be thinking.. why don’t you just step through the damn code?? Of course we do that! Most of the times finding an issue and solving is trivial. You don’t need scientific method or rubber ducking to solve those! However, once awhile there comes that bug hidden deep in code or even spread across multiple layers due to a design defect. It is then the rubber duck army marches!
I hear you TDD advocates! One might not even need to be so crazy as talking to a child's toy if there was validation before a single line of implementation code is written. However, in this world where shaving off a month in release cost would matter, only the plentiful would attempt it.
In conclusion my disguised rubber duck serves me well, and ironically help keeping my sanity in check.
