Why I'm not a fan of pair programming

Pair programming feels like a lingering ghost. Its adherents proclaim it to be the best approach to coding while the rest of us just continue to ignore it. I've only tried it a few times. Based on those few experiences, and what I read, I'm not interested in trying it again. I'm a huge fan of collaboration, mentoring, and code review, but this idea of sustained pairing just isn't appealing to me. Let me attempt to figure out why.

If you regularly do pair programming, please share how your experience contrasts to my opinions here. I'd like to see what I'm missing or misunderstood.

Dichotomy of experience

One of the tenets of pair programming is that both members must be equally contributing to the process. If this is not the case, then you end up with more of a mentoring situation. I love mentoring, but it's not the same.

Gaps in experience are expected in a job. I'm not just talking about "raw skill", I mean everything from one's familiarity with the code, to their understanding of the business, to their background in the field. Given any activity, it's inevitable that one individual is more suited to the purpose than the other.

With a significant gap, I don't see how a pairing won't just become mentoring. While it's great that knowledge will be shared, I'm uncertain how we could prevent a significant productivity drop of the dominant partner.

If I understood correctly, this gap is precisely one of the things pair programming is meant to address. It's supposed to narrow the gap. I can see this happening for a new project member, at least for the first month, but I don't believe the total experience gap will ever narrow -- it would imply the senior partner is remaining stagnant.

Serialized thoughts

Shared experiences require the individuals to think in a similar linear style. To be open to feedback it's important that my mind focuses on the code I'm writing. If I'm thinking anything, it's important that I speak it out loud, letting my partner share in my thoughts. My outward actions must clearly map to my inner processes.

The problem is that I don't work that way. The code I write is fragments of a total vision I have in my head. I'll come and go from various source files piecing together that vision. It'd likely appear chaotic at times. If you were to interrupt my stream and ask out the bits, you'd throw me off-track, and it might take me a while to collect my thoughts and explain.

Of course, I can explain the code I've written; it's important to be able to do this. The problem is the online requirement of sharing this knowledge. Pair programming is forcing me to serialize my thought process, which is a significant hindrance.

Continual sharing is also a load on the brain. Progress is massively hampered whenever the problem is too much for me to both analyse and speak at the same time. I'll admit this isn't true of most of our work, but these problems do come up.

Isn't it pair "coding"

Programming is about a lot more than just coding, refer to my article I'm proud to be a programmer. Yet in all descriptions I've seen, pair "programming" is really about producing code. Maybe it should be called pair "coding". The terminology itself isn't my concern; I'm wondering how it fits into the bigger picture.

I don't see coding as a distinct phase of the programming process. There's a continual flow between writing code, analyzing requirements, talking to other team members, writing a fix on another branch, doing research, posting to online forums, eating a thoughtful sandwich, then eventually coming back to the original code.

I'm suspicious of any process that allows individuals to allocate large chunks of uninterrupted time to pure coding. Something seems off. Were the requirements so clear as to not need more feedback? Was the individual's background such a perfect fit that they don't need to do any research? Pair programming is supposed to stave off such isolation, yet appears to require it at the same time.

Tooling and remote work

To a programmer that's optimized their environment, it can be a shock to work with somebody else's environment. Many minor changes, like colour selection, keyboard positioning, screen height, font selection, and more, alter my productivity. I can eventually adjust, but every time I switch results in a productivity drop. I experience this whenever I need to work on either of my laptops, when I do a live stream for coding, or when I connect to a remote system.

Remote is also a problem. There are a lot of benefits to being out of the office, either one day a week, or as a permanent remote worker. I don't see how pair programming, as envisioned, can work in this situation. The tooling I've seen isn't sufficient to support it. Both parties would be subject to a foreign environment, with an accompanying productivity drop.

Why not work together?

Perhaps my biggest critique of pair programming is this overriding need to work as a single enlightened individual rather than as two members of a team. Why can't both people be coding at the same time? Why can't one be writing tests and the other functional code? Why can't one be doing some research and the other tracking down a defect?

I've had good experiences with two people focused on a problem, but both working at it from different directions. There's a continual sharing of ideas, reviewing code, and asking for assistance. The team relationship is fluid and doesn't require anybody give up their tools. It also doesn't matter if there's an experience gap -- it's okay if they're working at different speeds, and the junior member has access to mentor as needed. Why can't this be pair programming?