Power of RDD

We hired a new guy at work. I was officially the new guy for 2 months, now we have someone new.

I was given the task to get him up and running since the experience was still fresh for me. Once he got his dev environment going, he would look over my shoulder to watch what I was doing.

At first, this frustrated me, because I spend a lot of time just reading the code and trying to figure out what it does. But, I embraced the challenge and started explaining my understanding of the code and how the PHP and the JavaScript frameworks tie together. When I was unsure of what magic was happening, we would either investigate the code for an answer or we would ask a more-senior member of the team for their understanding. By the end of the sprint, both of us felt much more knowledge about how the code works and that the code we wrote was better because of it.

I explained this phenomenon to a friend over lunch one day and he laughed and asked if the new guy was my “rubber duck.” I gave him my best I’ve-only-been-doing-this-professionally-for-a-few-months-so-talk-slowly look and he explained what the Pragmatic Programmer calls “Rubber Duck Debugging.” Basically, by having to explain a problem out loud, one is able to more clearly see the answer.

I think this is also a form of learning by teaching. Just to explain the problem in a logical way, I had to learn enough of the domain for it make sense. I could answer some questions based on what I learned, but when asked a question that I could not answer right away, I had to learn more in order to answer that question satisfactorily.

I think for an informal pair-programming exercise such as this, we were experiencing Rubber Duck Development. We would both alternate between explaining and learning. Having to articulate the problem and looking into the bowels of the code, we were able to reduce the magic and increase our understanding.