My eXPerience, 2 Years Pair Programming
The last two years of my professional life were spent as a dedicated practitioner of Extreme Programming (XP). One of the core principles of this software development methodology is to pair program. Because of my involvement in XP, I spent roughly 40 hours a week over those two years pair programing. This article is intended to share my experiences and learning from exercising this practice for several years. Read on as I delve into my time with the approach.
How Pairing Worked for Me
My exposure to pairing came from within a “lab” at a fortune 100 company. The lab was essentially an innovation space which was intended to drive faster delivery of higher-quality software products. Aligned with the concepts of Extreme Programming, the lab (of about 50 people) was divided up into small teams which work on their own software products.
Since work was done in pairs, an even number of developers on the team was most desirable. Frequently, there were 4 developers to a team. Work took place in pairs with a duplicated computer environment for each pair respectively. That meant that each member of the pair had a duplicated monitor and separate keyboard/mouse. A pair worked to complete an agile feature story in tandem: problem solving, coding, deploying, documenting, etc together. Our teams rotated pairs daily and rotated members from team to team every couple of months. This all got a little messy along the way from time to time, but that’s how it operated the majority of the tenure.
The Good
On the whole, pairing is actually a lot of fun! Solving problems together, getting to know your teammates like you never thought possible, and delivery with truly shared ownership is quite fulfilling. One of the biggest benefits of pairing is learning. When I was much more of a rookie programmer, one of my teammates was a 10 or 15 year programming vet. Just watching them program was extremely valuable. Since part of pairing is coaching and learning from each other, pairing with experienced developers skyrocketed my programming abilities.
The saying of “two heads are better than one” was proven to me in pairing. Talking through a goal and problem solving together almost always seemed to result in a better outcome, when done within a healthy pair. Even the most junior developer will bring the best idea to the table at times. Moreover, another developer asking “why” will tend to derail some senior developers’ urge to over engineer. These combined talents and experiences made pairs almost a “super coder” compared to an individual developer.
A good pair supported you and made you better in the moment, too. When someone was actively working with you, it seemed you are a lot less likely to take the easy way out. A pair also eased some of the most frustrating moments of programming such as when you have made some small error you don’t quickly notice, often your pair had caught it.
The approach also appeared to have created more aligned teams. It helped developers see more of the product code as fewer items are in progress at once. Further, it forced more holistic decision making rather than one talented cowboy coder on the team setting patterns that are difficult to reverse.
On top of all of these perks, pairing allowed teams to shift easily. On-boarding a new team member was fairly easy. They learned quickly by having an avenue for continual questioning and glean from example through their pair. Additionally, there was no “trust issue” as their pair helped to avoid any gotchas a newbie may accidentally fall into.
Effective pairing made for great team chemistry and brought me into the office looking forward to the day ahead.
The Skill of Pairing
As any famous proponent of the approach (think Kent Beck) will allude to, pairing takes a certain skill set. In fact, I would say it is a skill itself. Watching newcomers join the lab, I saw the same tendencies each time. The urge to point at the screen seemed almost uncontainable for most as they started pairing. However, their pair was looking at a different screen and had no idea where they were pointing towards. When programming as a pair, you must communicate your thoughts more than you ever knew possible before. For example, it was easy to see that you typed out a loop, but why did you want to iterate over that data. Referencing line numbers and which pane of the screen you are discussing is essential. You would never have realized how valuable the comment, “line 79 on the right” could be. But it soon became second nature for most in the environment. However, it quickly became apparent that a good programmer is not necessarily a good pair. Some could never fully adapt as well.
Another aspect of the skill is more about being human and communication. Learning to talk out everything you are doing takes time to become more comfortable with and skilled at. Being comfortable was another spot of friction for newcomers. Have you ever been presenting in a meeting and type your password incorrectly, like twice? You never do that otherwise, but when people are watching, things can fall apart. Well, pairing was like that, too. When you know someone is watching you code, it is like you never learned any programming syntax ever. This all comes down to a key concept: empathy. As a pair, you are trying to help your pair and make them stronger for the pair and the team. So, you have to learn empathy for simple, silly mistakes we all make, as well as their growth in the methodology. Once your pair begins to feel empathy from you, that is a critical step to effective pairing and adoption of the approach.
Keyboard time is an imperative to creating an effective pairing experience. If your pair keyboard hogs all day, only a focus ninja will be able to stay engaged. Continuing that empathy in a two way street of ensuring equal “driving” time transforms the paring lifestyle so much for the better. All of this centers around working together effectively. I found that doesn’t come naturally; it’s learned. Bettering this ability takes time and effort, but truly produced noticeable impact on the team and product.
The Bad
For all of the good I found in pairing, there are some negatives as well. A member that didn’t fully believe in the approach, was typically not a good pair. When no one wanted to pair with a certain team member, it was devastating to a team’s chemistry and productivity! Additionally, a weak link on the team could remain hidden for far too long. If the developers around them were strong in their skillset, then it was difficult for management to understand who did good work and who didn’t.
The Mob! When you are leaning into the principles of two heads being better than one, what did we do when someone called in sick or was on vacation? Suddenly, there was an odd number of developers. How did you pair? Well, someone can work on their own, which did happen some, to be honest. OR you Mob! Mobbing is exactly like pairing, but with 3 people. A mob will truly show your pairing skills as it takes extra attention to focus and execute your practices with excellence. It was rare a mob was truly enjoyed.
Finally, this might not be so bad, but when your work situation constantly depended on another person, you needed to be around at the same time. Thus, syncing work schedules was imperative. That’s not always convenient in modern life.
Remote Work
If you are constantly pairing, how did you work remote? Don’t all modern, tech-focused companies allow remote work? We always strived to be in the office. However, with travel, sickness, inclement weather and the like, I have done my fair share of remote pairing. I even worked 6 weeks with a pair that was in another time zone. Collaboration was always better in person if you ask me. But there are tools that make remote pairing a viable option. Although, it won’t be quite as much fun, you’ll still likely be successful as a team.
Does Pairing Work?
The most obvious question to raise is: does pair programming make a team more effective? Well, it certainly made a positive impression on me, but that is a feeling and not empirical evidence. Some empirical evidence has been attempted (study 1, study 2). You’ll read statistics that claim something like pairing entailed 15% more overall people hours, but reduced defects by 15%. I believe it. Evidence of that sort does truly seem to support its value, but if that’s the case why don’t all companies do it? Of course, there are more in depth reasons why companies work the way they do. Nevertheless, it would seem that pairing would be more wide-spread if it truly provided massively more success.
My single opinion would say it’s dependent based on a lot of factors. If you have a mixture of experience levels and variety of exposure with languages, systems, and tools, it really should be more effective. The shared learning and quicker elimination of those annoying stuck moments when you just don’t know what’s happening would almost have to work better. However, if you only work in one language and everyone has 10 years experience with the tech stack, I would wager pairing may prove less effective. Also, cultural openness to the practice would surely impact the success of a well-intended transformation to pairing. Much like any other approach, its success will depend upon the environment and people.
Tips, Tricks, and Recommendations
10/10 I say give pairing a try. When you do, these are some things I learned along the way that might help:
- Be intentional about pairing. Do things like setup the hardware the right way. Look at tools that help to facilitate the outcomes you need; like timers for keyboard “driving” time. Have a team agreement to really be open and try the methodology with full effort.
- Give it some time. Pairing takes emotional energy from collaborating constantly. The first two weeks of pairing, you get home from the office drained. After a while, though, it seemed many become energized by it.
- Do not be too dogmatic. Be reasonable. If you need to research how React Hooks work, take a little time apart and come back together to share learnings. Support the ultimate goal of learning, collaboration, and better quality by being practical.
- Take honesty to a new level. Pairing requires empathy and trust. Trust is partially built with honesty. If someone is not listening to your ideas or takes the keyboard away, tell them with respect, grace, and candor. If you both are dedicated to pairing, you will work through it.
- Get to know your pair. Working this closely with someone doesn’t happen very often in the corporate world. You might find you develop some great friendships along the way, too.
- Rotate. I saw teams fall into the temptation of paring with the person with whom you pair best. Well, you’ll probably both grow more if you pair with someone that you don’t work with the best.
My Conclusion
Now, if you were the person I share these thoughts with at a conference, you’d likely ask some of the following: Did pairing work? Was it worth it? Was it more effective? Did you like it? There are so many points to consider around pairing. I say its implementation must be situationally dependent. I am pretty sure that some of the most successful tech companies in the world don’t pair as much as I did. Thus, it can’t be considered a necessity. However, it clearly had its purpose in our lab and my career.
Our teams helped each other level up one another, grew together in our culture, and created some really good software as we paired. I really loved it! I learned that pairing can be about more than efficiency and effectiveness, too. It can be a culture. A, “ we’re in this together”. The last several years of my work life have been a blast! Paring is something that I believe in and continue to support. Teams that pair take on a challenge in a way, but do so with much to gain in my experience.
