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.
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.