Pair Programming

Published

I found this tweet earlier today that really accurately describes some of my thinking about pair programming as of late:

However, I used to think a bit differently about pair programming so I figured it'd be worth talking about why my opinion changed on the topic.

Before digging in though, I realized that this isn't the first time I went to write about pair programming, I even have a stub of an article here (just over 2 years old at this point!), and also a semi-popular post on pair code reviews (which is almost 3 years old now!).

I used to really enjoy pair programming, we heavily utilized it on my current team about 2 years back. At the time - it felt really useful and it seemed like we were able to iterate through our work at a rapid pace. However, I feel like that's no longer the case.

Now when our team is pairing, it feels like we're spending 2-3 maybe even 4x the time to accomplish a task that someone individually can accomplish directly.

I don't think this is the default with pair programming however - I think it just means we're over-using it rather than using it only when we need to.

As with everything, it's about trade offs

  • Some senior engineer, somewhere

Using pair programming to:

  • Onboard a new engineer to the team,
  • Tackle a gnarly bug, or
  • Explore a solution to a vague problem

can be really useful.

I no longer recommend pair programming as the default for well-jelled teams however. Instead, each individual should be able to accomplish any task on their own.