I recently wrapped up my employment as a software engineer at Home Depot, a company which does 100% pair programming - no solo work allowed! For reference, I worked for a year previously at the complete opposite end of the spectrum - every developer was an island with very little cross-collaboration. When contemplating if I should take the position, I tried to turn to the internet for experienced input and found it lacking. So here's my thoughts on the pros, cons and general considerations for pair programming.

Photo by Mimi Thian / Unsplash

Pros

  • Knowledge Sharing
    There's no better way to share knowledge between team members, both technical and business-oriented. When paired with someone who is both helpful and knowledgeable, you can learn more in an hour than you would in a week on your own.
  • Social Collaboration
    Soft skills are a skill set that often goes severely overlooked, and can even be more important than technical skills as you advance in your career. You can't have too many social skills, and pair programming really forces you to build those.
  • Software Robustness
    Some case studies have revealed software developed in a pair programming setting, in general, is more robust. Two heads are better than one, and people will think very differently when solving problems. Those small bugs like concurrency issues, null pointers or other data anomalies, subtle logic problems and so on are more likely to get caught when you have two brains working through things.
Developers working hard
Photo by Tim van der Kuip / Unsplash

Cons

  • People Problems
    No matter how optimistic you want to be, I believe some people's personalities just don't get along, and there's nothing you can do about that. This can lead to unhappy and tense feelings on both sides.
  • Decrease in Productivity
    This might seem strange, since a lot of people tout "increased productivity" as a benefit of pair programming. But in my experience, that is not the case. There's an old saying that rings true, "what one programmer can accomplish in one month, two programmers can accomplish in two months."
  • Mental Exhaustion
    Programming is already a mentally exhausting task, and it becomes even more so when you are not only thinking about the code and whatever complex problem you are attempting to solve, but also having to juggle properly communicating that, debating it with your partner and worrying about general social behavior.
what’s going on here
Photo by John Schnobrich / Unsplash

Neutral Considerations

  • Code Analysis
    This and bug investigation is nearly impossible. I dislike using the word impossible, but I strongly feel that proper system analysis in a paired programming setting is effectively impossible. Trying to walk through unknown code with someone else is just too difficult to do. People have different trains of thought, will want to investigate different leads and will soak up information at different paces. This is neutral, though, because I've found what works well is to instead split up to do analysis and reconvene in a set amount of time to discuss. Rinse and repeat as necessary.
  • Identifying Weaknesses
    Especially for junior engineers, I think the best way to highlight personal technical knowledge gaps is to get thrown into something over your head and work your way out. When you have someone there constantly to help you think, it sometimes masks those personal gaps. That can stunt growth. This one is neutral, though, because I feel like it's complimented by all the times you learn a bunch by pairing with someone more knowledgeable.
  • On-Boarding and Off-Boarding
    In general, this is a breeze. Since system knowledge is spread so quickly through the team, a new hire can pair with someone and immediately jump in to a system they're unfamiliar with and start contributing. There's no better way to get started. On the other hand, employees are more dispensable. The guy who's been there for twenty years no longer is the single source of business knowledge. That is a good thing for business, but I believe the fact of the matter is people are prideful. We enjoy having that ego boost, and we enjoy pumping our chest at a feature and saying "I did this all by myself, from the ground up." With pair programming, it's always "we," for better or worse.

Final Thoughts

Pair programming ultimately has a ton of benefits, but also drawbacks too. A lot of those benefits serve the company more than the employees, but the relationship is symbiotic. There are a lot of considerations to be made, and whether or not to take a job which heavily encourages (or even mandates) pair programming can only be answered on a personal, case-by-case basis. A lot of it really depends on who you are pairing with - get an experienced, friendly and patient partner and it can be the best thing ever. Get someone who is slow, frustrating or otherwise unpleasant and it can make you contemplate quitting on the spot.

Pair programming can have a place in the work environment, and should be encouraged. But like everything else in life, the truth often lies between two extremes. Having a team of engineers who shut themselves in a dark office the whole day is just as catastrophic as a team of engineers who are forced into constant collaboration.