the joy of pair programming

I started speaking about pair programming because I didn't like it and I needed to understand this practice better.

Sometimes I still don't.

But, I admit this:
Pairing is a great practice.

Great, but surprisingly difficult.

The ideal pairing situation requires both people to be expert developers. They need to be open to the other person's idea. And in this case (expert developers with good, strong opinions), its likely to bring pain.

If the pair is not parallel in skill (which is often the case), the stronger person must slow down and take on a mentoring role. Being a mentor when you want to be as productive as possible is frustrating. Many developers are poor teachers, but communication and discussing ideas is key to creating a great solution.

Every person you work with is different and you create a unique pair. You will go at different speeds, create different designs, even make different jokes.

Pairing is a good mechanism for teaching, but the real strength is in design and code. I have seen no other practice keep every team member familiar with every project, design and decision.

The whiteboard is rarely used because the pairing session isn't about code, its about creating. The design decisions are made when the pair needs to make them. Any previous design or decision may not be the best solution when (and if) its needed.

If discussion can be avoided, don't do it. The best way to be productive is to keep coding and evolving. Focus on small steps to deliver functionality quickly and ensures CI success.

With pairing every moment is a code review. If the team switches pairs and owns the code, everyone is familiar with everything. No reviews, no whiteboards, no documentation.

Imagine the possibilities.