August 01, 2017 • 2 min read
We pair program most of the time at Hashrocket, and as a result I’ve been pair programming almost every workday for nearly three years. I’ve seen when it works, when it doesn’t, and how it challenges people. And I’ve learned something: pairing is hard work.
There’s a misconception about pairing that it’s a fun and lighthearted affair. Two people sharing the work of one person. We talk loudly, argue, and laugh a lot– surely this can’t be difficult work. But I’ve found the opposite to be true: the thirty-five hours a week I spend pair programming is exhausting. It’s a constant challenge to my instincts as a programmer, and to our direction as a team. And it’s nearly impossible to ‘zone out’, an option I’ve found to be a major part almost every job.
When you’re pair programming, your ideas and instincts are under almost constant (friendly and professional) assault. The choices we make are informed by many personal factors; my preferences are not objective truths. Reasonable people can disagree and persuasively argue against almost every one of them. Ask somebody else to attach their name to a commit, and you’re going to get conflict. Conflict is tiring, and so this makes pair programming hard work.
Likewise, when you’re pair programming, your direction as a team is under constant review. As consultants whose livelihood relies on adding value, my pair and I are continually challenging our direction. Will this feature help get us to market? Is it MVP, or is it unnecessary scope? What is the easiest-to-install/best-maintained/most pragmatic tool to solve this problem? Not a day goes by with a pair where these questions aren’t rehashed again and again. Again, it’s worthwhile work that is nonetheless exhausting.
The toughest part of the paradigm, given that programming is a knowledge-worker field, is that you can’t really ‘zone out’. I’m talking about the mindless internet surfing and phone-checking that is a hallmark of the modern office. The peer pressure when pairing to stay focused on the task at hand is intense. Nobody wants to be the pair who derails the team’s momentum.
This social aspect can be extra exhausting. The fuel needed to be ‘on’ and engaged with another person all day is in limited supply. I have about eight hours worth. When it’s gone, it’s gone.
So why pair at all? To me, the increased quality of the work is irrefutable. If code reviews are good, then we should do them all the time, and that’s what pairing is– the best method around for ensuring other people understand your code on a deep level.
At the end of a day of pair programming, I’ve learned a ton, I’ve done the best work I know how to do, and I am drained. It’s totally worth it.