Does Pair Programming Work?
By: Lynn Langit
Tags: Pair Programming, JavaScript, Programming, Python, Software Development

When Pairing Works

Words matter. When I begin working via pair programming, if my partner is new to the technique, I usually don’t even use the word “pairing.” I remember how scared and vulnerable I felt when I tried to use pairing. I simply say, “let’s work together.”

I always start the first remote session with a video chat. I spend at least five minutes learning about the other person. I want to convey that I want to understand them as a person and that we will be working together as a team. If they seem nervous, I will often just have them watch me and ask questions (and help me by Googling when I get stuck), rather than having them type on their keyboard, until they feel comfortable enough to perform tasks via my direction.

There are three cases that most often work well for me when pairing. I classify these cases by my and their knowledge of the particular technology that we will be working on. These cases are as follows:

Me: Expert \ Them: Beginner

Me: Beginner \ Them: Expert

Me: Intermediate \ Them: Expert

First, on the expert-beginner pattern. A further nuance is that the role pairing depends on which type of technical work we are doing. One example is when I am creating technical courseware, code examples or documentation. I have found that the most useful pattern for this type of work, is that I’m in the expert role and my pair is a beginner. The reason for this is that to write and test usable examples, documentation, etc, it’s critical to have a beginner’s mind. A recurring issue in technical samples is an assumption of technical knowledge because the expert who is writing the sample is steeped in the technology already.

When creating technical courseware, working with a true beginner also helps me to appropriately level my courseware. I work hard to teach one concept at a time, adding layers as the course progresses. Beginners, who feel comfortable, have made my courses immeasurably better, by challenging my presentation of topics, outlines, depth of coverage, and so on.

Next, the beginner-expert pattern. Alternatively, I have found when I am producing software for customers, I often find value in the get the expert pattern. This is valuable in cases where I am a beginner (or intermediate) in a particular technology. An example of this is using a language or library unfamiliar to me. Working with an expert can speed up my output significantly.

One key component of this pattern is that I must feel comfortable. Unfortunately, there still exists in our industry a culture of allowing assholes with technical skills in one or more areas to be celebrated. It took me a while to understand that if I don’t feel OK asking the questions I have, then I won’t understand the solution and, ultimately, I won’t be able to provide value to my customers. If I can’t understand the code, I won’t change it — software that can’t be updated, etc, isn’t soft. In addition to functionality and usability, malleability is an essential aspect of the value of software.

Pair with experts, but only those that have a level of EQ that makes both me and my customers comfortable.

When pairing works, it’s a complete joy. Literally, it’s kind of like dancing with a skilled partner — swapping screen-sharing and keyboard back and forth as the ideas flow, feeling really happy, building great software together.