ajmurmann/Pair Programming Draft

## Pair Programming Draft

My first full-time Software Engineer role was at Pivotal Labs. We were probably still fewer than 50 people and of course followed all the Extreme Programming practices. Pair programming is one of the core practices and it stayed with me for much of my following jobs. I want to share how my views of it have changed and when it's most valuable.

I used to believe that it's most valuable to make pairing the default. This solves a lot of problems. You get collective code ownership, can probably eliminate code reviews, quickly have the team to gel around standard practices, knowledge sharing, more focus, higher code quality etc. (https://martinfowler.com/articles/on-pair-programming.html has a much better list of all the potential benefits).

I still believe that pair programming brings many of these benefits. However, it's a tool like everything else. How much value you realize depends on the context in which you use it which includes the problems your team is solving, what other tools and processes you are using and importantly the people on your team and their preferences.

##Knowledge Sharing
When practicing pair programming and proper pair rotation, knowledge sharing comes naturally. Everyone or most people on the team will rotate through work on a given area of the code base and thus are forced to develop a working understanding of it. This works really well on newer code bases, especially if it's frequently changing due to shifting direction and iteration towards product/market-fit.

As your project stabilizes, the team's collective knowledge of more complex code areas that haven't been touched in a while will start deteriorating. People will start forgetting and churn might simply lead to fewer people still being around who have worked on that area of the code base. This is when you will start missing written documentation. You need to think ahead and document complex work when you still understand it, as your project is getting more stable. There is no hard and fast rule for when you need to start documenting. Complexity of what you are doing certainly is a key factor though. Your Rails CRUD-app likely can do with no documentation, as long as you have tests and it's following best practices.

##Collective Decision making
When it comes to making architectural decisions <INSERT LINK TO PARKER's TALK> or laying down patterns that future code will follow, two pairs of eyes are certainly better than one. For larger architectural decisions pairing might actually be too light-weight. Depending on the scope of the decision it might be more appropriate to create a proposal that goes over different solutions and their associated trade-offs and discuss this with the team and relevant stake holders. This document could be the artifact of a pairing session that did some research spikes but certainly doesn't have to.

Another option might also be to correct in the other direction and lay ground work in a mobbing session with the whole team. This can seem expensive, but especially early on in a project this might dramatically cut down on feedback loops and lead to faster and better decision making.

##Code Reviews
Code reviews, especially PR reviews really deserve their own article. Pairing can be a very good substitute for reviews. This will work best if the team practices good pair-rotation and both people who are pairing have enough familiarity with the area they are working on that they can catch potential mistakes. If you only pair occasionally, and have knowledge silos on your team, you might still need code reviews and should make sure that they are done by the right people. A good compromise can be to have a culture of asking for additional review when you feel it's warranted. This requires a sufficiently mature team and some amount of psychological safety, but then what doesn't?

##Tracking Individual Performance
On teams that pair by default the manager will have to rely significantly more on peer-feedback than on a team that does not pair. Depending on the team's ability and willingness to give constructive feedback this can be a blessing or a curse. Feedback from pairing can be very detailed and immediate and actionable.

Not everyone is comfortable giving negative feedback directly or via the manager. This can make it harder to identify who the top performers are and propose concrete areas of improvements for others.

<TODO: how to work around this on teams that pair?>

##Should you do it?
As mentioned in the beginning, pairing is a great tool, but it needs to fit your situation. If your team is new or working on a new project and especially if there is a lot of product risk and likely changes, pairing will probably be very useful for your team. Make sure to adjust your other processes like PR reviews and documentation requirements to maximize the value you get from pair programming.

<TODO: WHAT ABOUT SYNERGY WITH OTHER PRACTICES LIKE TDD, ESTIMATION, ETC>

<TODO: COMMITMETNS RUIN PAIRING>

	My first full-time Software Engineer role was at Pivotal Labs. We were probably still fewer than 50 people and of course followed all the Extreme Programming practices. Pair programming is one of the core practices and it stayed with me for much of my following jobs. I want to share how my views of it have changed and when it's most valuable.

	I used to believe that it's most valuable to make pairing the default. This solves a lot of problems. You get collective code ownership, can probably eliminate code reviews, quickly have the team to gel around standard practices, knowledge sharing, more focus, higher code quality etc. (https://martinfowler.com/articles/on-pair-programming.html has a much better list of all the potential benefits).

	I still believe that pair programming brings many of these benefits. However, it's a tool like everything else. How much value you realize depends on the context in which you use it which includes the problems your team is solving, what other tools and processes you are using and importantly the people on your team and their preferences.

	##Knowledge Sharing
	When practicing pair programming and proper pair rotation, knowledge sharing comes naturally. Everyone or most people on the team will rotate through work on a given area of the code base and thus are forced to develop a working understanding of it. This works really well on newer code bases, especially if it's frequently changing due to shifting direction and iteration towards product/market-fit.

	As your project stabilizes, the team's collective knowledge of more complex code areas that haven't been touched in a while will start deteriorating. People will start forgetting and churn might simply lead to fewer people still being around who have worked on that area of the code base. This is when you will start missing written documentation. You need to think ahead and document complex work when you still understand it, as your project is getting more stable. There is no hard and fast rule for when you need to start documenting. Complexity of what you are doing certainly is a key factor though. Your Rails CRUD-app likely can do with no documentation, as long as you have tests and it's following best practices.

	##Collective Decision making
	When it comes to making architectural decisions <INSERT LINK TO PARKER's TALK> or laying down patterns that future code will follow, two pairs of eyes are certainly better than one. For larger architectural decisions pairing might actually be too light-weight. Depending on the scope of the decision it might be more appropriate to create a proposal that goes over different solutions and their associated trade-offs and discuss this with the team and relevant stake holders. This document could be the artifact of a pairing session that did some research spikes but certainly doesn't have to.

	Another option might also be to correct in the other direction and lay ground work in a mobbing session with the whole team. This can seem expensive, but especially early on in a project this might dramatically cut down on feedback loops and lead to faster and better decision making.

	##Code Reviews
	Code reviews, especially PR reviews really deserve their own article. Pairing can be a very good substitute for reviews. This will work best if the team practices good pair-rotation and both people who are pairing have enough familiarity with the area they are working on that they can catch potential mistakes. If you only pair occasionally, and have knowledge silos on your team, you might still need code reviews and should make sure that they are done by the right people. A good compromise can be to have a culture of asking for additional review when you feel it's warranted. This requires a sufficiently mature team and some amount of psychological safety, but then what doesn't?

	##Tracking Individual Performance
	On teams that pair by default the manager will have to rely significantly more on peer-feedback than on a team that does not pair. Depending on the team's ability and willingness to give constructive feedback this can be a blessing or a curse. Feedback from pairing can be very detailed and immediate and actionable.

	Not everyone is comfortable giving negative feedback directly or via the manager. This can make it harder to identify who the top performers are and propose concrete areas of improvements for others.

	<TODO: how to work around this on teams that pair?>

	##Should you do it?
	As mentioned in the beginning, pairing is a great tool, but it needs to fit your situation. If your team is new or working on a new project and especially if there is a lot of product risk and likely changes, pairing will probably be very useful for your team. Make sure to adjust your other processes like PR reviews and documentation requirements to maximize the value you get from pair programming.

	<TODO: WHAT ABOUT SYNERGY WITH OTHER PRACTICES LIKE TDD, ESTIMATION, ETC>

	<TODO: COMMITMETNS RUIN PAIRING>