Cover image for The Evil of Pair-Programming

The Evil of Pair-Programming

redfred7 profile image Fred Heath ・4 min read

Pair Programming is like sex. Done consensually and with the right partner, it can be a most beautiful and gratifying experience. Done under compulsion and with the wrong partner, it can traumatise you for life.

Pair-programming seems to be treated as a 'holy-cow' by many agile organisations. A sacred practice which should always be followed and yields benefits for everyone. "Pair-programming is great", I read. "Everyone should be doing it", I hear. Please excuse me while I call bullshit! I have done many pair-programming sessions in my career. Some as the navigator and some as the driver. I have also observed the impact from many, many more. Here is what I've learned:

  1. There is no 'right' style of neuro-cognitive functioning. Not everyone's brain is wired in the same way. Different people learn in different ways. Assuming that the interactive, synchronous and intense learning model embodied by pair-programming is always the 'correct' one, has no valid scientific basis.

  2. People have different biorythms. Some people are not fully functioning early in the morning or late in the evening, for instance. One of the best developers I ever worked with was unable to put two lines of code together most of the day. But in the evening, he was transformed into a highly-productive code-churning, white-paper writing, project-collaborating machine. My team used to joke that he was a 'were-coder', so radical was his transformation.

  3. Good technical skills != Good communications skills. Just because someone knows their subject inside-out and can write beautiful and effective code, does not mean they can successfully impart their skills and knowledge onto others, least of all in an interactive and continuous manner.

  4. Sociopaths work amongst us. I have noticed that software development attracts a proportionately higher number of sociopaths than other professions. Maybe it's because the sociopathic trait of cold, emotionless rationality is seen as beneficial in the software development world. Or maybe it's that sociopaths are attracted to money and our profession is a relatively well-paid one. I don't know. What I do know is that pair-programming with a sociopath, whether they are the driver or the navigator, is a traumatic experience for the unfortunate other member of the pair.

So yes, I have seen many cases of successful pair-programming. But I have also seen many others that ended badly. Some of the worst ones were:

  • The developer who was labelled a 'bad team-player' because he kept rejecting pairing with others. He was eventually dragged to HR, where he was forced to confess that he was on medication that made him short-focused and irritable and that was why he avoided pairing. Stigmatised and embarrassed he left the company soon after.

  • The developer who ran off in tears after their pairing navigator kept implying that they weren't intelligent enough to be a programmer, because they couldn't follow the intense pace of the navigator.

  • The new hire who quit after a month because continuous and constant pair-programming left her burned out. She was never given a chance to absorb knowledge at her own pace.

Alternatives to Pair-Programming

  • An asynchronous learning model. This is what we do when we go through code-reviews. But instead of waiting for the code review stage, we can implement a continuous asynchronous review process, where a developer posts their design, code or even thoughts on a special-purpose wiki (or a GitHub gist) in their own time and other team members can respond when and how they see fit. This gives developers the time to formulate their thoughts and assimilate the information received before asking the next question. It also gives reviewers the time to be more thoughtful about their responses.

  • Ping-Pong programming. This is a variation on pair-programming but it can be done asynchronously and is very focused.

  • A Mentorship model. This is where some team members are assigned as Mentors (or Subject Matter Experts) in specific areas or topics. The company allows time for these developers to help others in their chosen areas. Developers can then approach those Mentors to receive guidance on specific topics and within scheduled sessions.

Tips for successful knowledge sharing

For employers, development managers and team leaders

  • Do not compel people to pair-program. Always wait for volunteering and mutual consent.

  • Ensure pair-programming happens in short, time-boxed sessions. Never allow all-day pair-programming.

  • Ensure pair-programming sessions are focused and scoped in specific areas,e.g. how to implement a design pattern, or the fundamentals of a new framework, etc. There should always be a learning goal at the end of a pair-programming session.

  • Do not advertise pair-programming as a company perk, or even as a best practice that should always be followed.

For developers

  • If you see a company advertising or boasting about pair-programming, run the other way and don't look back.

  • If you think someone could benefit from your knowledge or expertise, always ask them first if they would like your help. If they say yes, then ask them how would they like you to help them. Pair-programming should be one out of several options for you to help them.

  • If you need help from another person, always ask them first if they have the time or energy to help. If the say yes, then ask them what's the best way for them to transmit their knowledge. You should give them several options, including pairing.


Pair-programming is a sharp tool. It can yield tremendous benefits or do terrible harm. Use it with caution.

Posted on by:

redfred7 profile

Fred Heath


Fred is a software jack of all trades, having worked over the last 23 years at every stage of the software development life-cycle using a plethora of languages and platforms.


markdown guide

Scheduling a 4-hour pairing session between two people who want to pair together is magic. Hyper-productive.

Also, freaking exhausting. You do 4 hours and then go home and sleep. The idea of doing it every day probably sounds great in management magazines, but in reality it's impractical and flawed.

A decade ago there were some companies that were 100% pairing and they attempted to imply that if you weren't doing it like them, you clearly were not as good.

Horseshit then. Horseshit forever.


Exactly, full-time pairing is counter-productive in the long-term and leads to burn-out. Sadly, there are still a few companies that push this ill-thought practice to their staff.


Pair Programming is like sex. Done consensually and with the right partner, it can be a most beautiful and gratifying experience.

I just had to stop myself as I began laughing my ass off.

Sociopaths work amongst us.

YES. Too many ways to make our work better, like remote work or Agile, rely on the assumption of a low douchebag to normal people ratio. I have worked on small Scrum teams where we popped through a project like fresh bubble wrap, and others where the presence of that guy meant we got nothing done.

The reason for some methodologies, like Agile, is to enable your best developers and those most likely to act in good faith, to remove obstacles. These tend to rely more on "individuals and interactions."

Other methodologies and processes, on the other hand, exist to force your shitty devs acting in bad faith to not actively sabotage things in the name of some misguided careerism. These tend not to have anything to do with Agile.

I'm very careful nowadays to assess what kind of people I'm dealing with before I decide whether to start putting "People over Processes" and doing other high-effectiveness agile-type stuff.

Ever read "In Sheep's Clothing"? I have experienced that first hand.

Should be required reading for CS majors.


I haven't read 'In Sheep's clothing', so just bought in on Kindle :) The late Pieter Hintjen's 'the Psychopath code' is another good book on the subject.


Pair Programming is like sex. Done consensually and with the right partner, it can be a most beautiful and gratifying experience. Done under compulsion and with the wrong partner, it can traumatise you for life.

Honestly, comparing pair-programming to rape is incredibly insensitive.


I'm sure OP's intent was not to offend anyone. It's an analogy—admittedly an exaggerated one, but it gets the point across well: Being forced to do something you didn't consent to. Obviously one situation is worse than the other; I don't think anyone here is implying otherwise.


I understand what an analogy is - and this doesn't get the point across well, unless you really think that rape is as incidental and impactful as a... workplace organisation issue. Which it isn't.

There's a really toxic culture prevalent in tech and usually this site manages to avoid it. It's disappointing to see it cropping up here in an otherwise interesting article. You wouldn't think you'd have to tell men to not compare a programming practice to literal sexual abuse, but here we are.

I can see both sides of it, actually.

On the one hand, you could have a reader who experienced rape and sees it being compared to something much, much less atrocious, walking away disgusted. On the other hand, I think most readers will understand that the analogy was meant to be a lighthearted joke—one that doesn't intend to trivialize rape or cause offense, even if it does end up doing so.

I can't really speak for OP, but I think he deserves the benefit of the doubt here.