Pair Programming

Pair Programming is a great way to write better code and disseminate knowledge through the team at the same time. Counterintuitively, pairing has been shown to increase, not decrease, overall team velocity long-term – even though engineering man-hours are higher overall.

What is it?

Pair Programming is a coding technique involving two engineers. One will be the driver, who writes the code and navigates the IDE. The other will be the navigator, who will review the code as it is written. The engineers sit together and discuss their thought process and approach as they code, and they switch off often to allow both to drive.

Why?

Pair Programming works because it encourages thoughtfulness in code so that effective decisions are made.

• It helps divide up direct coding responsibilities to the driver, and more abstract, strategic thinking to the navigator.
• It disseminates knowledge between engineers to break up knowledge silos.
• It helps increase developer’s skills long-term.
• It results in significantly higher-quality and more thoughtful code.
• It has been proven to raise developer satisfaction.

How?

There’s two things you can do:

1. Make it a priority to accept requests to pair.
2. When you have work to do, ask someone to pair with you.

As a team leader, I strongly recommend that my engineers pair as much as possible. Although there’s often initial friction to the idea, developers consistently report higher satisfaction with their work, the end result tends to be much better, and it helps increase your bus number (in other words, it disseminates knowledge, which is a risk point in team leadership). Ideally, you should spend 50%+ of your coding time in a paired session.

Notes

• The driver does not need to be (arguably should not be) comfortable with the problem area.
• Remember that the idea is a collaborative problem-solving session as opposed to a teaching session.
• The best pairings are between senior and junior engineers.
• The best problems are those that are harder, or require a higher degree of creativity or process.
• Avoid “disengagement” – when one engineer isn’t interacting in the process. If this seems to occur, switch off positions.