(Originally written here.)
I could argue (to varying degrees of success) that pair programming isn’t productive. Productivity of a practice is an easy thing to attack because, in our capitalist dystopia, it’s the end-all-be-all metric. But I hate pair programming, and it’s not just because I don’t feel productive. It’s a lot more than that.
Five years ago I was an unpaid intern with a twinkle in my eye. Every technology and every practice was new and exciting and my brain was a sponge. As I progressed out of the internship some of these practices (e.g. testing, version control, continuous integration) became invaluable tools that I’d reuse countless times. Others didn’t prove their worth, or were trends in disguise. That’s okay, it was a net-gain.
It was this mindset that attracted me to pair programming. I even insisted on my co-workers trying it out with me. “We will be able to share context,” I would say, “and bypass the code-review process!” At the very least I wanted to get a barometer on how effective it was, but no one at either of my first two jobs wanted to take me up on my offer.
Then I got a job offer from a large company that loved pair programming. In fact, it was a requirement. Without much hesitation I switched jerseys and embarked on my doomed foray into eXtreme Programming.
My first red flag was exhaustion. Working with people is great and all, but when it’s one-on-one for eight hours a day it can be quite tiring. Especially if you don’t particularly care for someone.
The worst part, as an introverted person, was the kind energy I was exhausted of. I found friends impossible to keep up with, and I had barely any social energy to spend with my partner. Keep in mind: I just spent all day talking about code.
Continuous exhaustion can easily lead to burnout and depression, and I found myself battling with both. I won’t divulge too much, but some days were quite dark.
Do you have special keybindings or a preferred editor? Maybe you’ve been lovingly crafting a set of dot-files, or like to arrange your tmux in a particular way. Maybe you’re colorblind and need certain color-schemes, or fonts under a certain size are really hard to read for you. Well, kiss it all goodbye because you now have to share an editor and configuration with hundreds of other engineers. Anything that was personal preference before is now decided by committee.
The fact of the matter is, physical computers weren’t designed to be used by two people (with two separate needs) simultaneously. Remember all those tools I picked up that I had talked about before? Most of them were precluded by pair programming.
At its best pair programming is inconvenient. At its worst? Downright ableist.
A tenet of pair programming is that it promotes learning through context sharing. Personally, I found this to be a fallacy.
I found watching people rip through vim buffers incredibly hard to learn from, and as time went on, it became embarrassingly apparent that I had major knowledge gaps of our systems. The problem is two-fold:
Firstly, regardless if the onus was on me to tell my pair to slow down, or my pair to be considerate of new learners; Watch The Master Syndrome is real. Engineers are so eager to showcase their skills that things can quickly spiral out of hand.
Secondly, not everyone learns the same way. For example, just because one person learns great by sitting down with someone and watching how they work, that doesn’t mean it works for me too. I find documentation and deep-dives on code much more beneficial, and I’m sure there are many, many other learning styles.
Remember when I said that some practices became invaluable tools, while others didn’t prove their worth? After two years of pair programming I knew it was time to leave aforementioned company and try something else. That said, don’t let my disdain prevent you from trying it out. You may learn a thing or two about yourself; I know I did.