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.