It’s a lot worse than wasted time. A LOT worse

What is Pair Programming, Really?

No this is not a definition contest. Some readers think pair programming is a great collaborative exercise, others see it as a monstrous indignity. I am one of the latter.

We’re having a great nomenclature problem in software right now. Imprecise terms are replacing precise ones and communication is disintegrating into intelligent-sounding buzz. It turns out that most references to pair programming are wrong. Not every activity that has two people working on the same desktop computer is pair programming.

Let’s start with what pair programming isn’t.

It Isn’t Mentoring

A more senior developer demonstrating concepts to a more junior one is not pair programming. This is mentoring, and working hip-to-hip is not a good way to do it. I prefer calling it “teaching” because “mentoring” already sounds like buzz and we need to use a lot less buzz in our biz.

A senior developer spending hours or days getting others up to speed is a senior developer who is not writing features or fixing bugs. If the teaching is one on one then it’s time poorly spent. So this should not go on for days. Any developer at any stage should be something of an autodidact, able to learn from books, Udemy courses, online documentation, whatever. If he can’t, he’s in the wrong business.

But if a senior developer is going to mentor others it should be in something more like a classroom setting with more than one learning and his audience should include every developer in the company not up to speed on the topic.

It Isn’t Design Discussion

Planning a new feature is not pair programming, and sitting at a PC is not the right way to do it. You don’t write the code before the design (you don’t write the tests before the code either but that’s another topic). Design discussions should be attended by a subset of a development group; it may be a pair of people, it may be more. And design discussion is at the very least a second step.

It Isn’t Code Walkthrough

This isn’t pair programming either. New developers, or developers being introduced to a component, should be able to learn most of what they need by reading code but in practice, the implementation logic is split across many classes and files and it’s helpful for someone familiar with it to give some guidance. pointing out where pieces of the implementation live, explaining why things are designed as they are.

But again. doing this in a one-on-one condition is an inefficient use of time. Everyone who hasn’t worked on the code in question should be in the walkthrough.

What It’s Supposed to be

The actual intent of pair programming is based on an impossibility - that two people work together on the same computer, either hip-to-hip or on a shared screen. It is billed as a continuous code review. The idea is that they will routinely swap roles, one entering code and the other critiquing it. Writing code while engaged in discussing it. At the same time. Anyone who thinks it’s possible to write code of any but the lowest quality during a continuous interruption has no business being anywhere near a code editor.

Basic Assumptions

Coding Requires Concentration

This goes back fifty years or more. Software developers who can enter and maintain periods of uninterrupted concentration do much better work and a lot more of it than people who can’t. This was called flow, and its cultivation as a top management priority was the reason for Microsoft’s long-vanished greatness.

Flow is a fragile state, difficult to enter and easily broken. Any meeting destroys it for the rest of the day.

Developers who can’t concentrate, or whose concentration is capriciously broken by interruptions, get a lot less work done and write significantly more bugs. If you dispute this then you have never experienced it, and it’s possible you never will.

If you disagree with this you may as well stop reading now.

Interruption Destroys Concentration

You’re deep into your work, juggling a head full of detail. BZZZZT. Time for a recurring meeting, only held because it’s on the calendar and it’s not going to be canceled nor is it going to let out early just because there’s nothing to talk about. To managers at most companies, wasting others’ time is the very definition of authority.

You go to the meeting, occupy a chair while others drone on in meaningless buzzwords strung together (refactoring, technical debt, stories …), struggling to stay awake.

When you get back to your desk your earlier thoughts are gone, your momentum is gone, and while yes you continue to work the earlier focus is lost for the day.

Meetings are the worst, and all the methodologies entail ridiculous numbers of largely ceremonial meetings. But there are also notifications (turn them off) and summoned distractions like social networks; yes we can turn those off but there is nothing we can do about “team” events.

Pairing is Continuous Interruption

Communication and concentration cannot happen at the same time. When you have to listen to someone else or say something, your focus is broken. You may or may not be able to restore it.

In the halcyon days of Microsoft before it changed from a software business to a business business we were all instructed to never interrupt someone working. We were each issued a sign reading DND for Do Not Disturb that we put on our closed office doors when we were concentrating. We had desk phones but were instructed to not use them without good reason. Coffee and drinks were free, not out of generosity but so we wouldn’t interrupt someone else’s work looking for change for a pop machine.

Protecting us from interruption was management’s primary function.

We got a lot of work done, and we loved how we were treated. In pair programming there are no respites from interruption. It’s continuous. It assures that both will work at their lowest level of performance, but then, having never known concentration, they have no idea what they’re missing.

Pair Programming Models

Let’s contrast three different configurations and show what it wrong with each of them, in addition to the complete suppression of concentration.

Junior-Junior

Two inexperienced developers sit hip-to-hip entering and critiquing each other’s amateur work. This is like trying to win at gambling when nobody at the table has any money. Wisdom doesn’t come out of thin air any more than money does. Certainly, one may know a trick or two that the other doesn’t but the time would be much better spent learning more about software development from books, and pair-reading is not a thing.

Senior-Junior

The junior developer will be an onlooker and the best that can happen is that he won’t interrupt the senior’s concentration with too many questions. More likely the senior developer will work at a vastly slower pace, entering a little code and explaining what he’s doing to the other.

This isn’t programming. This is mentoring. At best. The junior’s contribution will be minimal and the senior will be yearning for some privacy.

Senior-Senior

In this scenario there are two developers, both of whom work much better alone, working together on the same thing, significantly reducing the individual productivity of both. Experienced people have strong ideas about how to do things; if they are congruent in this, one of them is superfluous; if they are not, you have conflict.

In any case the two of them could be working alone on different projects instead of wasting time working on the same one, so this circumstance is supremely ridiculous.

Psychological Harm

Wasted time though is only the beginning. Pair programming has two people working so close that there is a violation of personal space; they are closer than most spouses in bed and for some people, your writer included, this is hideously uncomfortable. And to be compelled by manager orders to work in what amounts to sexual proximity is grotesque.

Legacy and New Developers

Those like me whose early work was in private offices are accustomed to unbroken concentration and find pair programming to be painfully intrusive.

One of my former managers, later at another company where pairing was ordered for all developers, had his entire senior development group come to his office as a delegation and tell him that if the pairing continued they were all quitting. They would rather have to find new jobs than go on working like that. Management was forced to concede; they would have gone out of business.

The more junior developers, lacking the leverage to make such a demand, continued to do pairing. Several of them ended up in therapy and at least one of them ended up hospitalized from the stress. This is mitigated by pairing remotely but that does nothing for the broken concentration. Screen sharing is the hijacking of a computer; watching someone else’s mouse cursor, unable to scroll or select.

On the other hand young developers who have never known saner times think that having two or three recurring meetings every day and having to work in uncomfortable proximity with people they may despise is just “the way it is.”

“It Should Only be Voluntary”

Oh yes. Managers are completely understanding that some people don’t want to obey whatever insane orders they’re given. Sure. As if anything in any corporate workplace is voluntary.

Stop lying to me.

We all have to work with people we don’t like. This can’t be helped; I have had to lay boundaries many times, such as demanding that a coworker not talk to me about anything not related to our work because of his bigotry, his rallying for the Second Amendment, his right-wing politics made me sick.

Pairing With Someone You Despise

But then there are those people we simply can’t stand. The one time I had to pair program my “partner” was one of those hyper-obedient lackeys that Microsoft favors so much, a guy I could not stand. I had four times his experience yet during our three-hour session he went to my whiteboard to explain polymorphism to me, something I had learned when he was an infant.

He was condescending and intolerable, and when after a sleepless night I emailed him that I could not continue this he came to my office the next morning anyway and pulled up the chair, clearly planning to do this all day. I resigned from my job ten minutes later.

This had been the intent all along. Microsoft was about to have its first layoffs ever and managers had been instructed to get as many as they could to resign so when the announcement came the numbers would be lower. My father had just died so they figured I would be easy to push over the edge. Pair programming was torture.

Lasting Psychological Harm

In 1983 I had a housemate who had a psychotic episode and tried to murder me. He knew how to throw knives, he threw one at me, it barely missed me, and went into the wall up to the hilt. If it had hit me I would have bled to death.

I’ve been in three major auto accidents; in two of these a single centimeter difference would have left me quadriplegic or dead.

I’ve gone for years without thinking about any of these. I could’ve died; I didn’t. Move on.

Eleven years after those three hours of pair programming I was still having daily episodes of panic, biting my knuckles, and breathing hard. The memory would not fade. Last year I was diagnosed with PTSD, which I thought only came from combat, and spent thousands of dollars on counseling; I wrote about it a half dozen times till I externalized the experience as words on paper. I still think about it but the panic symptoms are finally over. I drew some satisfaction from learning that the manager who made me do it had died seventeen months later.

During those three hours, I would have done anything, I would have confessed to murdering JFK (I was nine) just to get that lickspittle out of my office.

But Some Claim to Like It

This I cannot understand. They are always a generation or more, younger than I am; I have never met anyone over 35 or so who doesn’t feel much as I do about pair programming. It’s only younger developers who have never known concentration on the job, who think pairing has any benefit. Given how awful the experience was for me I cannot even begin to understand how others can see it so differently. I think a lot of them are trolling.

Then again, they see nothing wrong with being constantly interrupted, since they have never really learned to concentrate anyway.

Abolish It

Many tell me that pair programming is largely passé now; no, managers have not conceded its harmfulness but simply take the view that two people doing the work of one (or less work) isn’t cost-effective.

But my own experience, and others I know of, says that this is at its core a sadistic practice. Certainly, Microsoft was seeking to get me to quit, and it worked. Being a weightlifter and having no stage fright I thought I was psychologically too strong for the effect that it had on me for over a decade. I wasn’t.

I had one more onsite job that I enjoyed but after that, I left the USA and have only worked on distributed teams or freelancing. But were I to ever find myself in an interview again and pair programming came up in any context other than “we don’t do that here,” I would walk out without a word.

And any manager who would order people to work like that should do a few years in prison.