Pair programming. Understanding of this topic may vary among the readership.

Some of you might have the vague notion that it means two programmers working together… or something. Others of you might have a more solid grasp of particulars and a vocabulary that includes terms like “driver-navigator” and “expert-novice.” And, a few may even understand the full origin story of pair programming as a core plank of the eXtreme Programming (XP) approach.

Hey, Look, a Pair Programming Reader Question

I’ll soon return to that origin story. But first, let’s look at why I’m talking about this at all. I’m actually gearing up to answer a reader question:

I was interviewed by a company that [does] full pair programming. I hate the idea of spending all my day with somebody looking at me writing code. What do you think about it?

So to clarify a little here, we’re talking about a company that subscribes, full stop, to the XP rule that “all production code is pair programmed.” For all intents and purposes, this means that dev teams pair program 100% of the time as a rule.

Should you take a job at such a company?

It’s honestly hard for me to say for any given person since my advice would be so very tailored to your individual personality and preferences. So rather than immediately give a thumbs up or down, I thought maybe I’d explore the topic of pair programming more broadly.

Since my publication of Developer Hegemony and subsequent departure from a traveling consulting/training life, I’ve made this blog increasingly one about software developer empowerment. Today, I’d like to look at the subject of that pair programming through that relatively uncommon lens.

I want to examine not whether pair programming is a Good Thing (TM), but whether it’s a good thing for you , as a software developer.

Understanding my Pairing Biases, Such as They Are

Before I do that, I should acknowledge past work along these lines and writing on the subject. Frankly, it’s all been pretty pairing-positive.

• I did a course for Pluralsight in which I helped software developers make the business case for pair programming to skeptical management.
• I’ve written how-to/explainer posts professionally, like this one for Stackify, about pair programming.
• And I’ve participated in pairing a lot over the years in situations ranging from the ad hoc to the formal.

But, on the flip side, I’m also a pretty textbook introvert. This leads me to regard pair programming personally in the same way I do open office plans: fun, tiring, and not how I feel most productive.

And this leads me to a relatively bemused point of view: able to make the case that pair programming benefits the team/company perhaps more than the individual, at least for some individuals. This is important to consider for the remainder of the post.

I say this because I’m going to argue that there are actually a number of reasons to be leery of this work situation, notwithstanding its effectiveness.

XP and the Origin of Pairing as a Popular Practice

But first, let’s return to the pairing and XP origin story. I wasn’t there, of course, so I won’t offer narrative details or editorializing, per se. But it sure looks like a handful of prominent developer-consultant types (who would later sign the so-called agile manifesto) came together and said, more or less, emphasis mine:

Hey, if things like code review and test-first approaches are good things in programming , let’s take them to the *extreme * and see what happens.

And it turned out that what happened was good. It went well enough that it generated early wiki pages, articles, books, etc. And the rest, as they say, is history.

Now, of course, this inspired an industry of emulation. We, as a working society, love nothing more than to attempt to reproduce things that went well for others. And, why not. This is one of the most fundamental ways to learn and grow.

But it also bears consideration that the XP rules were opt-in for the developer-consultants authoring them — “hey, what if we did X, let’s try it and see what happens.” But those opt-in rules will be mandatory for you, the workaday dev, 2 decades later, as you debate whether or not to go work at this company.

The Case Against 100% Pair Programming as Desirable for You, a Developer

With the backdrop securely in place, let’s get to the meat of it. I’ll go into my reasoning for why you might want to pump the brakes on accepting such an offer.

Please note that this only applies to people skeptical of 100% pairing. I’m not talking about a company where developers sometimes pair, which is, frankly, probably 90% of companies with more than one developer. And if you really like pairing, then, by all means, take the job. The approach has a ton of upside, and you like it, so go nuts.

The case that I’m making here is orthogonal to the efficacy of the practice, and understand that I’m not weighing in on whether or not teams should adopt 100% pairing policies.

1. The Throwback Emphasis on Physical Presence

Let’s start with something easy to grok. A lot of the practices and philosophies of the 1990s movement toward “agile” are meat-space focused, which makes sense for an era of fax machines and Citrix, or whatever. You sit in open office plan bullpens, write things on physical note cards that you stick to a wall, have daily stand-ups, and sit next to someone at a desk all day, every day.

In 1999, sure. But in 2019… really?

If you go get yourself a seat at any enterprise agile transformation, you’ll see an emphasis on change. In some cases, it’s change toward the modern: ditch the dress code, install Jenkins, do DevOps, etc. But, in some cases, it goes the throwback route: get out of the project management tool, use a dry erase board, and get everyone into the same room.

And so we see “throwback as progress” when it comes to development approaches. Now, I’m a fully remote worker and fully remote business owner, and have been for years. So I’m obviously biased, and I’m not going to lobby for remote over physical presence in this venue. (I’ll just say that it’s hard to imagine ever going back.)

But I will point out that a 100% pairing team/company is disproportionately likely to have rigid policy around butts-in-seats. If you’re pairing 100% of the time, it’s hard to justify risking a flaky remote collaboration tool. And it’s also hard to justify any kind of flex hours.

So you’re probably looking at a job where you need to be in your chair from 8:30 to 5:00, ready to interact socially, or else you’re letting your team down.

2. A 100% Pairing Mandate is Ipso Facto Micromanagement

Switching gears a little, let’s talk agency (or lack thereof). All of our devs pair 100% of the time is a formalized micromanagement policy.

Over the years and in my coaching/consulting travels, I’ve dealt with constant chafing between managers and developers on the subject of unit tests. I hear things about management not letting developers write automated tests. And I hear things about management wanting to see unit test coverage.

I advise management to knock it off. They shouldn’t be meddling in developers’ unit tests any more than they should be in how frequently they compile their code or check Stack Overflow. How the developers work should be up to those developers.

So how is the decision to pair or not any different?

There’s a particular irony here, given that agile methodologies tout flat structures and self-organizing teams. There was, of course, no hypocrisy when Kent Beck et. al. created the methodology because they were self-organizing when they laid out these rules. But you’re not self-organizing when you join a “pairing mandatory as official policy” company.

So understand that you’re joining a company that micromanages how you create software.

3. You’re Joining a Company Where Extrovert is the “Correct” Personality Type

Let’s get something out of the way. No matter how many talks I see on “pairing for introverts” or whatever, pairing is decidedly not for introverts. Honestly titled, those talks would be “Slightly Mitigating Your Inevitable Exhaustion and Burn-Out.”

But you don’t see this kind of honesty. And the reason you don’t is because of the extrovert ideal that Susan Cain defines in her excellent book on introversion. With the rise of the salesman persona, extroversion became the “correct” personality.

Think about school growing up. If you didn’t like the idea of group work or if you wanted to read a book at recess, the teacher felt a need to “correct” your behavior so that you wouldn’t earn the “anti-social” label.

This carries on into the workplace. If public speaking, group work, schmoozing, and small talk make you uncomfortable, the world tells you that you need to fix yourself to get ahead. “Here are 5 helpful tips that will cure you of that backward impulse to like solitude.”

Not all companies are equal in terms of embracing the extrovert ideal. And you can safely bet that a company demanding 100% pairing is outstripping the competition when it comes to trying to fix your broken introvert personality.

4. The Company is Playing Not to Lose

I’ll get more into the benefits of pairing for the company in the next section, but a big part of that benefit involves keeping developers focused and relatively mistake-free. The flip side of that is that you don’t have bursts of individual creativity and inspiration uniquely afforded by blind alleys and “unproductive” digressions.

Take the iconic (though apparently debated) example of Google’s 20% time. The essential premise is “we believe enough in our employees that we’ll give them a day each week to work on whatever they want, however they want, and trust that their undirected efforts will somehow pay off in seismic gains.”

That’s playing to win. It’s the equivalent of a football team up 14 in the 4th quarter and throwing downfield anyway. 100% mandatory pairing, on the other hand, is kneeling on the ball and then punting in that metaphor — playing not to lose.

A policy like this indicates that the company is primarily interested in predictable velocity out of the development staff, rather than brilliant ideas or game-changing developments. And there’s nothing at all wrong with that — it’s perfectly rational. The expected value of predictable, error-minimized work is going to be higher than the expected value of blind alleys with the hope of game-changers.

I’m mentioning this only so that you understand what you’re likely getting yourself into: a company that wants you to plug away predictably and unremarkably for 8 hours a day.

5. Subordinate Status Signaling

I’ll close with an argument that’s somewhat challenging to capture in just a few hundred words. I expanded on it at length in Developer Hegemony, but I’ll Cliff’s Notes it here.

Developers in mandatory pairing arrangements give off more of an air of juniority/subordinacy than their peers who are free to work as they please. To understand what I mean, consider three undeniable benefits of pairing as far as the business is concerned.

1. Collective code ownership spreads knowledge around the team and lowers “bus factor.”
2. Pairing means constant code review, which means fewer escaped defects and design issues.
3. Developers in pairing situations won’t face as many distractions and interruptions.

All good stuff, right? But now, let’s look at it through a dispassionate, corporate valuation lens. Here’s the CFO looking at you.

1. Pairing makes individual developer resources more fungible.
2. It helps overcome the inherent sloppiness of software developers.
3. It prevents developers from engaging their natural tendency to goldbrick.

And, once the CFO is done with her stroll through the open office bullpen, do you think she heads back to her table and pair-CFOs with her pair-CFO?

Of course not — that’s not something leaders do. She heads back to her office and works alone. In fact, this is not something even scrum masters, project managers and analysts do. It’s something that only developers do because only developers need accounta-bili-buddies.

Of course, nobody is saying this stuff, or probably even consciously thinking it. It’s just the subtle vibe that will permeate the organization. And it will tend to make leadership less inclined to listen to developers and to make technical positions “stickier” for anyone interested in lateral transitions or moving into leadership. At least it will until you can find a way to extract yourself from giving off subordination signals.

The Case for 100% Pair Programming as Desirable for You, a Developer

This section is going to be comically short and sweet. For me to make the case against 100% pairing took an awful lot of explanation. To make the case for it is easy.

Ask yourself this:

1. Do you enjoy pair programming and the thought of doing it all the time?

If the answer is yes, then go for it. Highly collaborative dev teams are effective, and this approach is good for the company. If it’s also good for you, then you’re signing up for an “everybody wins” kind of situation.

Mandated pairing has a number of subtle downsides for your individual career (and some not-so subtle, if you’re an introvert). But it also has some huge upsides for you, including:

1. Really, really quick learning if you’re new and working with more experienced folks.
2. Experience early and often as a mentor/coach, potentially leading to nice consultative career opportunities.
3. A crash course in office politics and navigating others’ personalities.
4. A hard to replicate sense of camaraderie with your team when it goes well.
5. Higher likelihood of making friend-associates that will last the duration of your career.

And, of course, you’re ideologically aligned with your company and its interests. And I can’t think of any circumstance where that’s a bad thing (provided you don’t go idealist and lose sight of your own interests).

So, Should You Take the Job or Not?

Normally, any article that weighs the pros and cons of something cops out in the conclusion with “so, as you can see, it depends and it’s up to you.” I’m not going to do that here, because what’s the fun in that?

Given the framing of this reader question, I would suggest to this reader that you probably should not take this job.

I’m an introvert, and I’m not a huge fan of group work. But I did find that each time I took a gig that was more collaborative than I was used to, I wound up enjoying the collaborative situation more than I thought I would. Not only was it not a nightmare, but a more open office plan or more pairing on the job actually proved enjoyable.

But it also tended to prove not sustainable, either. I’d work all day collaboratively and then work extra hours after everyone left because all of the collaboration didn’t feel like real work. Eventually, I’d tire, not from the long hours, but from the constant collaboration. And I’d move on or maneuver to a different project or role.

My point is this. You’ll probably enjoy the pairing more than you’d think. But given your gut proclivity, it will also probably wear on you.

There are a lot of companies out there with a lot of different philosophies. I’d find one that hews closer to your your own.

The post Should You Take a 100% Pair Programming Job? appeared first on DaedTech.