Pair Programming

Five years ago I was an unpaid intern with a twinkle in my eye. Every technology and practice was new and my brain was a sponge. As I progressed 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. Yet, 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 rule. Without much hesitation embarked on my doomed foray into eXtreme Programming.

Why am I tired all the time?

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 no social energy to spend with my partner. Keep in mind: I spent all day talking about code.

Continuous exhaustion lead to burnout and depression, and I found myself battling with both. I won't divulge too much, but some days were quite dark.

The Personal Computer, made impersonal

Do you have special keybindings or a preferred editor? Have you been crafting a set of dot-files, or do you like to arrange your tmux in a particular way? Perhaps you're colorblind and need certain color-schemes, or fonts under a certain size are hard to read for you. Well, kiss it all goodbye. Now you have to share an editor and configuration with hundreds of other engineers. Anything that was personal preference before is now decided by committee.

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? Pair programming precluded most of them.

At its best pair programming is inconvenient. At its worst? Downright ableist.

Why aren't I learning anything?

A tenet of pair programming is that it promotes learning through context sharing. I found this to be a fallacy.

I found watching people rip through vim buffers hard to learn from, and as time went on, it became clear that I had major knowledge gaps of our systems. The problem is two-fold:

Regardless of 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 spiral out of hand.

Not everyone learns the same way. Because one person learns 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. There are many other distinct learning styles.

After two years of pair programming I knew it was time to leave 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.

© 2018 Patrick Brown