The Mortifying Ordeal of Pairing All Day

From 2014 to 2020 I was part of an experiment: I paired all day, most days, for years. Hundreds of other engineers joined me in this experiment. I was working as a software engineer for Pivotal, in Cloud Foundry R&D, and everyone paired, often for eight hours a day.

This was one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software. It also burned me out. Not “I don’t want to think about work” burnout. Not even “I don’t want to work ever again” burnout. “Sorry… how did that sentence start? What were we talking about?” burnout.

I was on short term disability due to cognitive impairment for several months of 2020, and I’m still recovering my old attention span, executive function, and emotional management.

I also believe that the expectation that everyone pair, all the time, led to technical and product failures at Cloud Foundry.

There’s a response I often get at this point, especially from people who were managers in the organization at the time:

“But Nat, teams weren’t expected to pair all the time. XP says to pair on all production code, but there’s more to software development than production code, and Pivotal management didn’t require teams to pair all the time. If a team wanted to pair less, they could.”

This is true. Pivotal teams had a lot more freedom than they realized they had. I spent a lot of my time there helping people realize that. I would often spend one or two days a week soloing.

And yet.

Teams had half as many workstations as they had engineers.

We were Pivots, and one of the things that made us Pivots was that we paired.

One of the great and terrible things about XP, is that it operationalizes peer pressure. It harnesses drives that humans have, drives for identity and belonging, in the service of producing software. These forces were only tenuously under management control.

So I paired all day, most days, for about five years. This had a lot of upsides, far more than I can list here. There’s a standard list of benefits and drawbacks to pairing that you might be familiar with, but the impact of pairing, especially pairing that much, goes much deeper than its impact on the code, on the particular work the team delivers that week.

Have you ever played Overcooked? It’s a great game. 1-4 people co-operate to process ingredients into finished dishes, in a variety of terrible kitchens. On one level, earthquakes periodically split the kitchen in half— you can move ingredients and dishes from the upper half to the lower half, but not the other direction.

It’s actually a game about pairing, and queuing theory.

I’ve played this game with Pivots and non-Pivots. With non-Pivots, there was a lot of shouting about how the game is impossible, and arguing about how to proceed.

With Pivots, typically the team got 2 (out of 3) stars the first time they played a level. Then, a short team debrief, the team plays again, achieves 3 stars, and moves on.

We enter drift together. We make decisions as one.

This is the real power of pairing, intense pairing. Talking about what you’re doing, and adjusting it based on the input of other humans, becomes automatic. For a kid who grew up being told that I had “poor social skills,” hated “group work,” and just generally didn’t understand other people, this was an almost psychedelic experience. I transcended my individual limitations and experienced a higher form of consciousness.

I remember once, walking down the stairs at 875 Howard, and re-entering the low hum of thirty or so pairs, and thinking, “Ahhhh. I return to the collective.” I understand why Borg drones would fight so hard against being rescued.

But: cognitive impairment.

Months where I struggled to meet my own basic needs.

Pairing requires being vulnerable, to another human being, for hours at a time. Intimacy, both physical and mental. I had to share space, decisions, thought processes, and often feelings with this person.

This never stopped being draining. Even with an easy pair, where I could achieve that synchronized transcendence without effort, pairing well requires staying engaged with my environment, with my pair. No retreating into sensory experiences, no checking my phone, no wandering off or getting distracted. Maintaining that level of focus for hours at at time was thrilling, but it also required a serious exercise of will.

There were some pairs where it required more than will. I had to fight to stay engaged. I had to develop skills. There were people with whom I disagreed, but with whom I struggled to resolve those agreements. There were people who didn’t put nearly as much thought into my experience as I was putting into theirs. There were people who expected me to “just grab the keyboard” when I had an idea, despite working so fast that I didn’t understand what they were doing. There were people who just made me anxious or uncomfortable.

I had to confront a lot of my fears about myself. I had to learn to show someone else all the things I didn’t know, my limitations as a human and a software engineer.

Over time, over years, pairing wore me down. Took a little bit more each day than I could recover. Until my life was working, and recovering from work, and then working some more.

And then the pandemic happened. Overnight, suddenly, I performing this daily act of will without the support of the office, without the famous Pivotal breakfast, without anyone to talk to except my pair, while the world burned down around me.

I crumpled. I stopped being able to pair. Stopped being able to have a conversation.

This wasn’t everyone’s experience with pairing. In a two-by-two grid where one axis is “sensitive to the demands of pairing” and the other is “time committed to pairing” I’m hugging the upper left hand corner. My experience was extreme.

And yet.

Pivotal Labs, I’m told, had a reputation as a “burnout factory.” Many people left Cloud Foundry in part to escape from the demands of daily pairing. People who love pairing, who see the benefit of it, but who despite all those benefits are tired.

There are people who can pair indefinitely, for years. Who don’t experience the most demanding version of it often. Whose recovery capacity comfortably outpaces the demand. A lot of those people, at a place like Pivotal, end up in management roles, in leadership roles, and then they miss pairing. Pivotal had a leadership staff that, even when they believed me when about how demanding pairing was for me, couldn’t really see it themselves.

We’ve all heard the bad reasons not to pair. “It’ll just slow the team down.” "It'll just slow me down." “It’s great for learning, but…” “It’s fine for just banging code out, but it doesn’t work well for exploring.”

I’ve dismissed these people myself as fundamentally unprofessional, unwilling to do the hard work of real software development.

Now, though, I hear those objections, and I hear fear. A fear that I share. A fear of exposing my vulnerability, my ignorance, my soft parts, and a fear of the cost of that exposure, of the cost to my mind and my body of subjecting myself to that exposure, day after day, in exchange for a paycheck.

Underneath the urge to dismiss those concerns, I hear another fear. A fear that pairing is too hard, that people wouldn’t choose to do it if they weren’t corralled into it by peer pressure and equipment affordances. That a “pairing culture” is such a delicate wisp of a thing that if you allowed engineers individual workstations, they would abandon it immediately.

What did we miss out on, by failing to make more space for people not to pair? By treating this pairing culture as something so fragile, and so precious?