This post is part of a series:
- Introduction
- The Good
- Individuality And Creativity
- Code Quality
- Odds & Ends
As this tale of pair programming comes to an end, I wanted to share a few things that didn't exactly fit within any larger themes.
Where I work we do something called promiscuous pairing. This is where you switch pairing partners at a specified interval - in our case, that is every 4 hours. So you pair with two different people every day. It has some nice benefits in that you don't have the same knowledge of a story wrapped up within one or two developers who pair together all the time. But it also has some challenges as well.
One thing that I've really struggled with under this setup is a feeling of fatigue from not being able to see a feature through to completion. Often, you will start a feature with one team member and then after lunch, you will join another pair working on something else and you never get to see your solution to the feature completed. Those little wins are one of the most rewarding feelings about programming and I didn't realize how much I'd miss them until I didn't get to see them.
As you might expect, the reverse is also tough. When you join with a new pairing member whom was already in the middle of a feature, they've got a lot of knowledge of the intended solution in their heads which can make the new member feel at a disadvantage. Not only can the existing member take a dominant hand in writing the code while the new member of the pair flounders, but the new member may not have the couarge to speak up and offer new ideas towards the solution.
The last thing I want to mention is a comment I saw in a Pragmatic Programmers article on pairing:
"If you are the weakest player on the team, you will find that pairing gives you an opportunity to learn from your teammates."
That's a very rosy outlook. I can say for certain that the team I'm working with currently institutes a trial period for new developers on the team and has kicked members off the team for not being up to snuff. Those rules were in place before I joined the team, but my experience has led me to believe that pairing works much better when most developers are at the same competence level. Otherwise, it's more a mentoring or coaching role where one person is going to dominate the other to "teach" them.
So besides getting all of this off my chest, what was the purpose of these posts? I wanted to take stock of the good and bad things I've experienced while pair programming for the past year. I wanted to capture my feelings. And I also wanted to be able to do some analysis. I feel like a lot of the material I've read about pairing is not about the experience of pairing and the feelings involved, but rather purely the technical benefits, real or perceived. They often don't consider the human part of the equation.
Simply complaining about something is not useful. What I've been trying to do lately is take some of these things and figure out ways to minimize the areas that cause friction while enhancing the areas where pair programming makes a lot of sense. I haven't implemented anything long enough to report results yet, but stay tuned! Perhaps there's yet a way to make pair programming an enjoyable task.