On pair programming

While I have heard of such term before starting Hack Reactor, I haven't experienced first hand what pair programming is like. Well, 2 weeks in, I've had plenty of pair programming experiences. And here are my thoughts on the process.

To those unfamiliar with how pair programming works, let me explain. There are quite a few paradigms about how to do this but the basic one is the driver-navigator paradigm. In this, one person, who is the "driver", is in charge of actually typing out code. This person only needs to be concerned with syntax and logic. The other, who is the "navigator", doesn't actually do any typing, but instead has to be aware of the bigger picture and is in charge of translating ambiguous goals into small chunks of viable objectives that can be coded. In addition, this person needs to point out any mistakes the "driver" may have. Frequently, the two programmers can switch roles to ensure balance. This division of labor ensures that each programmer can perform his/her best when focusing on his or her specific task of being a driver or navigator. This combined effort will net better result, i.e. fewer bugs, more diverse solutions to a given problem, than when two programmers work independently on the same project. Or at least advocates of this programming method say so.

Now, does this actually work in practice? At times, I admit that I felt my productivity was significantly reduced. As interested as I am in seeing how others approach a particular problem, I always like to do things at my own pace. Also, in some pair programming experiences, I often notice since I'm usually the laid back type, I often clash with a pair partner who is more adamant. For instance, when I navigate, I often find myself not being able to effectively jump in and guide the driver since he/she is so determined to not let others guide and to only dictate their programming workflow as if he/she is the sole developer. On the other hand, when we switched roles, I, as the driver, often feel forced to take my hands of the keyboard and (let) the navigator "take the wheel". Of course, not all my pair programming experiences ended up this way. I find that with some partners I am often able to perform better than I'm soloing. I find myself catching bugs that I would never have caught when soloing. But that only happens when both my partner and I are of the same relative frequency on the personality spectrum. Besides improved programming design, I also get a chance to develop learning how to verbally communicate complex ideas as well as work out differences in opinions in attacking a problem, which is a very important part of my development as a software engineer. An additional benefit is that when I verbally express my line of thinking to another, I also get a chance to examine my assumption about how my code works and have a better picture when something in my code doesn't perform as expected. This process is similar to how rubber duck debugging works. By talking aloud to a rubber duck about how I want a piece of code to behave and what objective I'm trying to accomplish as well as assumptions that I make, it gradually becomes clear what the error in my line of thinking is and that way I can begin to fix it.

Overall, even though at times I thought my productivity slipped, the gains from pair programming were really worth any discomfort the programmer may feel. However, I think depending on the team dynamics and individual characteristics, not all programmers will benefit from this method of programming.