Getting Smart With Rubber Duck Debugging

Listen to the audio version of this text.

Coding, communication, visual design and marketing can all challenge us in unexpected ways when we’re neck-deep into our projects. For this reason, it is important to have a self-sufficient tool for clearing a path forward when problems arise and the work comes to a stop.

Enter the concept of rubber duck debugging.

Many of us have had this experience: you begin to explain your issue to someone else, and then you figure out the solution on your own before they even get a chance to say anything.

This is the idea behind rubber duck debugging. It refers to explaining your issue to a "rubber duck": an outsider to your process, or even a lifeless object that knows nothing about your work.

The method forces you to go through every part of your project in your head once again, and you end up taking another look at everything you’ve built. You will have to start from the beginning, and you must explain what you are doing to the rubber duck down to the last detail.

The reason why this works is that are the experts in our own process. We know exactly what steps we have taken in our work and likely have everything we need in our heads to solve the problem at hand. It’s just that as we seek to move forward quickly we often don’t keep every detail readily available in our memory for easy access.

This problem-solving process is then making clever use of ourselves as the key resource for moving forward. Rather than placing your trust in the completely clueless rubber duck, you are using yourself as a knowledge bank for your project. The focus remains on your own decision-making, and you end up examining your own choices closely.

In essence, we are placing a lot of confidence in ourselves with the rubber duck debugging method. We give ourselves the chance to be very thorough and critical without having to take a negative stance against our own work. As we take on the role of a teacher, we become more likely to spot issues with our work, because in order to explain it all to someone else, we must understand the inner workings of our code and our project as completely as possible.