Rubber Duck Debugging

The life of a programmer can be a tough ask; don't let anyone try to tell you otherwise.

We all have to admit that when developing any application (or part of) we’re bound to make mistakes – some of which can take us hours to spot and troubleshoot. When the fix or change is complex, those hours might be justifiable, but when you spend a considerable amount of time trying to fix something that should take just a few minutes, you’re likely to resort to calling in a fellow developer.

In most scenarios, while going through the code with your colleague you might just end up face-palming yourself when you manage to solve the problem while explaining your code to your colleague.

So, why didn’t you spot it before? Most of the time we tend not to read the actual code but rather skim through it and assume code is there or should be doing what is in our head. In reality, all you needed to do is read your code line by line and explain what it does to your cat, desk plant or your yellow rubber duck. Obviously your rubber duck (cat or plant) do not know how to solve your prob- lem but explaining your code to your duck will help you slow down, be more precise and thoughtful while going through the code. Basically it will help you pay attention to what’s really written. This method is known as “Rubber Duck Debugging” - a term which first appeared in 1999 in the book “The Pragmatic Programmer” by Andrew Hunt and David Thomas. Become the rubber duck This isn’t some zen philosophy for problem solving, or is it? Well, just because rubber duck debugging works for you, it doesn’t mean that you shouldn’t spend time with your colleagues to help them debug their problem. On the contrary, as someone who believes in this methodology you should make yourself available to your colleagues and become the rubber duck. All it takes is a small amount of your ‘precious time’ (and patience) to offer your undivided attention and listen to your colleague’s problem. No, this is not the time to preach about your favourite framework and how it could have made their code more efficient… it’s a time to listen. In most cases, your colleague will know more about their code than you do anyway, so listening is key.

While this may seem a waste of time/resources, there are a number of advantages to being your teammate’s rubber duck:

• No matter how much more experienced you might be, there is always something to learn from another colleague. Sitting down together and going through their code is a perfect opportunity for you to learn from your colleague’s methodology and coding techniques.

• If you are in a lead position then you’ll be the ultimate perfectionist and want to know exactly what’s going on. So, this will also serve as an opportunity to review the code.

• Once you do this a number of times – sitting, listening and not proposing any solution - your colleagues start to realise they are capable of solving problems within the code by themselves simply by slowing down and talking to their rubber duck. The lone rubber duck If you’re a lone programmer, talking to yourself to solve the problem will only take you so far – although it has been proven to increase cognitive functioning – explaining the problem to a third party is where the process has success. Hence rubber duck, or other inanimate object which becomes the focus for the task, especially when there’s no other person in the room. So, there are plenty of rubber ducks available to purchase online and, should the idea of a rubber duck staring at you on a daily basis be disconcerting, there’s always an online Cyberduck available as a substitute.

Either way, the message is clear, when faced with a programming conundrum, the rubber ducking method has great results. The trick is to know how soon to implement it – because while endless thought loop is a foul situation, more time spent means someone’s going to have to foot the bill….

All it takes is a small amount of your ‘precious time’ (and patience) to offer your undivided attention and listen to your colleague’s problem. No, this is not the time to preach about your favourite framework and how it could have made their code more efficient… it’s a time to listen. In most cases, your colleague will know more about their code than you do anyway, so listening is key.