The mortifying ordeal of pairing all day

Pair programming generates visceral responses due to it being introduced as if it were fact, which for me always triggers my spidey senses. People who didn't like it were told "you're doing it wrong" or "you didn't give it a proper chance". Dismissing criticisms out of hand only furthers distrust, regardless of the actual value of the idea.

I played along and paired for awhile, but now steadfastly refuse to pair, ever. I work best within my own mind, and the distraction of talking to someone breaks my concentration such that I'm unable to keep the big picture in my head anymore. The irritation of being that close to someone and having to engage with them for even half an hour is draining, and I took more frequent and longer breaks because of this (much to the annoyance of my pair-partner, who couldn't work while I was away).

There may very well be people who work well in pairs, but rest assured that there are those who aren't built that way. Don't disparage them, don't discriminate against them, and don't play the moral superiority game with them. Accept their diversity and be a better team for it.

I also worked at a company where pairing was mandatory for 8 hours a day. Plan was concocted by two tech leads who, of course, didn't pair themselves.

The exhaustion was visible, and productivity was very low. Since everyone vocally thought it was a "waste of time", there was a Fight-club-style "rule" where we couldn't talk about the downsides in public or even in Scrum meetings. We missed several deadlines for an MVP, code quality was abysmal and the product barely worked.

It stopped when the CEO took issue with it. He gathered the team to ask "why is the productivity so low?". There was an awkward moment where a junior dev was trying to answer but a tech lead was trying to tell him "don't break the rule".

It was an absolutely surreal experience, but not out of place in that startup.

EDIT: I also remember one of the tech leads complaining during a Sprint Retro that some of us weren't reading Slack fast enough, and we said "well, I was paring, I wasn't at my computer", to which he became a bit agitated and visibly angry. It was an awful place to work.

I’ve had incredible experiences pairing.

There were whiteboards, snacks, rating each other’s themes, and jokes.

What worked very well was to pair for conceptional problems, like architecture and defining modules and their interfaces. Commit some types and pseudo-code.

We’d then break away and work at our own speed and in our own style using the common foundation.

Come together to integrate and discuss.

Pairing is also worth it’s weight in gold for debugging. It’s like a rubber duck, but doesn’t feel wrong.

It is of course of utmost importance that both parties enjoy it. Else it’s pain and a waste of everybody’s time. I had a colleague who hated it like the plague. In which case short code/review cycles worked best.

A good tool, if employed correctly. Like most things, really. And fuck management if they force it down on me.

Since the comments here are mostly people appalled by the idea of pairing - try it before you knock it. Even the author says there's a lot of benefits to it, but it wore down on them over time.

I did pairing for a few year at a company early in my career. Some days it felt draining, but I learned a lot, quickly, from working with senior engineers and seeing how they approached problems or building systems. You even socialized different dev tools and terminal commands (I felt really smart when I taught a much more senior engineer about git push -u).

I also liked how it helped keep me engaged on days when I was tired and unfocused, and that the day was over at 5pm - you packed up and went home, and were disincentivized from doing more work until the next day.

Several years later, I'm pretty comfortable coding solo, but it's a nice tool to pull out when it's helpful (like ramping up on a new codebase).

I can't imagine pairing full time, but I did it for brief stints as a customer of Menlo Innovations. All customer code must be written by pairs, but one option to reduce costs is to have the customer supply half of the pair team, so I did this for a few half days one one project.

This is obviously scary at first because someone is going to watch me code! It turns out that it is perfectly normal to use google/stackoverflow to write programs, and I actually found the experience reassuring once I got past the shock of having someone look over my shoulder.

My team does not do pair programming, but I understand why Menlo does it, it it works great for them. Some benefits I saw were:

1) It is great for junior developers. It's like turning mentoring up to 11. This means that it is much easier to hire people because you can fill seats and actually train people.

2) They have a special kind of family friendly culture where people have their infants in the office. One half of a pair can be holding their 3 month old and still contribute as half of the pair. I think they get slightly less keyboard time, but it still works.

3) Developers changed projects a lot. Splitting the day between two projects seemed normal, and 3-4 different projects in a week was standard. The pairs provide some continuity during these transitions.

Major down sides include the fact that you can't visit HN during work time. That means that the opinions here are likely to be skewed.

There are places and situations where pair programming isn't a good fit, but after seeing it in practice, I think there are also places where it is a good fit.

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

Red flag for all kinds of weirdness if you're made to take on a company-based identity.

A few years ago, I worked on a project for about 11 months with one other guy and we paired almost all the time. Yes, it was mentally exhausting, yes we had some natural resistance to it at first. But damn was it effective, in producing higher quality code (two eyes on the code, two people to work out every problem or bug, always having someone to ping ideas off), in terms of knowledge sharing (we both understood every single bit of the code) and in terms of shipping on time. It was a complex project (reliably delivering large libraries of content to fleets of airplanes over satellite internet) and we delivered it from start to finish in under a year.

Some mornings I would wake up and really not want to pair, but I'd do it anyway because its what we agreed we'd do, and after an hour or so, I got over it and we were super productive. Sometimes I miss it, especially since I'm mostly working on my own these days.

I don't work there anymore, but last I checked with former colleagues the code was still ticking along in production with no issues.

When pairing, its important to take regular breaks and also to not overdo it (don't work overtime). It IS mentally draining. Most people are also naturally resistant to the idea and I don't think it can work unless all involved people buy into it. But I found it was the most effective way I've ever worked and also quite rewarding.

This is an introvert's nightmare.

The "fear of being vulnerable", or "showing my limitations as a human or engineer" are so secondary to the emotional drain of having to be that close to a person all day, every day at work, they don't even show up on the horizon of concerns.

Pairing is incredibly useful and valuable, but doing it all day would be hell.

If someone told me that they wanted me to pair for the majority of my day, or even the majority of code I wanted to write, the first thing I would pair on would be a letter of resignation.

As someone who worked in an all pairing shop for two years (run by a bunch of former Pivots), I can confirm it’s pretty draining, though my experience wasn’t nearly as bad.

I actually liked pairing a lot of the time, and still think it’s an excellent way to onboard into a new code base, even in a non pairing shop (I even miss it sometimes!). For me, the main drawback after a while was that I felt like I was less efficient when pairing on stuff I knew how to do, and my personal growth as an engineer was stunted because I could always lean on a more experienced pair. Since that was my first eng gig, my second job had quite a steep learning curve as I had to figure out how to debug and navigate on my own, without talking through it out loud.

How the heck can people work like that for 8 hours? I start to get very worn out at 2 hours of conversation.

I worked for a shop that adopted the Pivotal model and I can say that it was hell on Earth. If you check the research data it is obvious that pairing is only effective in some very special cases like: knowledge transfer for new teammates, onboarding people, getting juniors up to speed, solving __very__ complex problems. For your everyday work it is not only draining, but also a waste of both of your time. What makes it even worse is that your downtime will double because of pee breaks, coffee breaks, lunch breaks. People rarely feel the need to go at the same time. Nowadays if I'm interviewing somewhere one of my first questions if they have adopted this madness or not.

Sounds like the underlying reason is a link between performance and endurance. If you're achieving very high productivity, you can't do 8+ hours per day every day.

I wonder if it would possible to find a balance of doing shorter days / working fewer days, and offsetting that by being more productive in the hours that you do work.

When I started my first job programming job out of university, I spent a lot of time pairing with one of my teammates (online) at the beginning. Not necessarily because it was enforced, but I think we figured it would just be a good way to learn. This went on for a few months, over time I'd take shots at doing tasks for myself, some with more or less success.

Then eventually that teammate moved to a different team, and suddenly I was doing a lot more stuff on my own and... I learned WAY faster. I suddenly realized how dependant I was being when we were pairing all the time. Call it a self-discipline issue maybe, but if I ran into a roadblock I'd just ask him for the solution cause otherwise it felt like I was wasting time to not figure things out for myself. But once that crutch wasn't there, I had to think about things for myself more, and it was like a couple week before I was feeling way more confident in my skillset.

Project management is fundamentally about managing human psychology. This is a horrifying prospect, because we do not truly understand human psychology at a mechanistic level, much less to the point where it can be applied to the individual.

Therefore, we instead seek refuge in processes and rituals that are, for practical reasons, not validated by experiment. One can hide almost any issue in a forest of obtuseness. If something doesn't work out, one can always blame it on some failure in adherence to the dogma.

I like pair programming.

Now, it is important to understand that, when you pair with somebody, not everybody has the same stamina or they might have worse day when you have your better, etc.

I set limits on pair programming. It seems to me 4 hours of true focus is a limit for most people on most days and pair programming requires constant focus whether you are driving or observing.

Other 4 hours are left for administrativia, some other smaller tasks, personal learning, making up for the stuff you were too embarrassed to ask during session, etc.

--

As to comments that talking constantly breaks your concentration and slows you down -- yes, it does and at the same no, it does not.

It is just a different way to achieving the outcome.

If you are programming alone you have better ability to focus, you can start/end when it is suitable for you, you don't need to consult every single part of design.

But what is left is that you are making mistakes on your own (and the longer it is uncorrected the higher the cost of fixing it) and there is no other person that knows how the stuff you developed works.

So while you yourself program a little bit slower, you are also achieving other goals concurrently with writing the code -- getting it honestly reviewed, passing knowledge, etc.

I have also found that verbalizing and explaining what I do many times causes me to find issues that I could have probably missed.

--

I personally like pair programming especially when I want to transfer some of the techniques and reasoning I use when developing solutions. This is not something that can be passed through presentations or reading and explaining the code.

Is it just me or is it trivially easy to get all the benefits the author describes without the downsides? Maybe just do it fewer hours for fewer days. Build in enough time for full recuperation. I'd say half as many workstations as people is definitely asking for trouble.

There's also the other extreme, Mob Programming, where you get everyone in a room together with one projected screen.

The idea is you can have several people in the room thinking and researching while someone drives and others observe. The idea is it keeps everyone in the loop. I've never tried it but there's some long videos floating around of an example in work.

https://mobprogramming.org/

First off - I feel terribly sorry for the author's experience and I can totally empathise to it. Also want to share my personal experience and some mitigation techniques. I was pairing 8+ hours per day from 2012-2017 with 10+ engineers in total, most of that time fully remote. My company highly praised Pivotal and its processes, specifically pair-programming. Similar to the author, I have experienced different levels of engagement from my peers, conflicts, etc. I can 100% agree that pair-programming is extremely physically/mentally exhausting. Even just to talk for 8 hours/day puts your brain under extreme pressure. Here are some of techniques I've learnt and employed to mitigate the negative consequences:

* Talk through the pros and cons of pair programming with your new pair upfront. Ideally have your thoughts on the topic already written in a doc. E.g. clarify the difference between the dynamic: person behind the keyboard (driver) is generally thinking slower (spends time on typing), while the observer have more time to think. Explain the importance of switching the driver regularly. Explain the benefits of being the driver: e.g. if a person wants to build up the context in a new area it might make sense to be the driver and learn at slower pace. Ideally switch the driver every day.

* Agree on the scheduled regular breaks. E.g. I used to have a pomodoro timer for 45 mins and then a 10 mins break. When working from office having a game of ping-pong/pool is a great idea. When remotely just switch off from the computer to relax a bit. This also helps with distractions (e.g. Slack, Email, etc): use that time (and only that time) to manage the distractions so that you can have your full focus while pairing.

* Do frequent retrospectives and give feedback. At the end of the pairing day ask "What did you like/did not like?". Try to be honest: it is important to catch factors that irritate/annoy early and fix them rather than letting them grow into a bitter relation.

More importantly be inclusive: pair programming just doesn't work for everyone, there's no point to force someone in to it. It is worth a try though. I find its benefits hugely overweigh the downsides.

edit: formatting

It takes a long time to get over the kind of Stockholm Syndrome an employer like this creates. The OP is at the first stage: disengaging and trying to get perspective. At some point hopefully they will see that they were being psychologically manipulated to meet a corporate goal without any concern for their individuality. That to me is the definition of a bad employer: they want units not humans.

I could deal with this for maybe a week. 6 years is just mind-bending. Incredible endurance/tolerance.

Agree with many sentiments described here. I was one of the early pioneers in this area, starting with XP in 1998. At the time, it was cool because it was counter culture, rather than cargo culture. I remember having to get approval from the president of our 500 person company to come in on our own time on a Saturday to take down a cubicle wall, so that we could have a larger collective space.

Some pairings were a delight to participate in; others more strained. But when it worked, it was super cool. It was like that dribble attack on the goal where you just read each other's minds.

One thing we learned early on though, was that any real debugging didn't work well this way. We even codified it as "debugging break" where we would split apart and sort of mumble aloud the different things we were seeing as we pursued our various intuitions and hunches.

Now days, I rarely pair anymore. The skill gap in my current team is pretty varied. The sense of self is strong, which generally goes against the "us before I" gestalt of pair programming. I do find when I need to answer questions or demonstrate, I tend to put myself in the passenger chair and turn it into a pairing experience for the other.

> 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.

This can be true of any demanding job.

Pairing is like running or cycling together. One person will be faster or have more endurance than the other. The slower one must set the pace or they will get exhausted quickly. For sustainable daily pairing, I would expect the team to quickly develop a hierarchy of speeds, with the lower speed person in every pair controlling the console.

I had so many negative experience pair programming that I started to find ways to avoid it.

There were the pairs the insisted on using vim[1]. There were the pairs that hogged the keyboard. I'm sure there were other things that frustrated me about it (it's been a long time since this was an every day thing now). In the end though, I opted out of pairing, first by taking a devops role at the same company that didn't require it, and later by not applying to any company that had that as a requirement.

To be clear, I'm not against pairing occasionally, but overall I prefer to be alone with my thoughts while programming -- not having to negotiate every little thing with a new pair.

If that doesn't suit the company, then so be it.

[1] I have nothing against vim, and I even know how to use it's basic functionality, but it's a huge barrier to being involved and efficient on someone's computer.

I can only pair effectively if I feel fully comfortable with the person I'm pairing with, and I would not feel uncomfortable disclosing who meets or does not meet that criteria at work.

Software engineers tend to be less comfortable socially so I imagine other people share this perspective.

I worked at a place where pair programming was optional but suggested as a good practice. I worked there for 5 years. It was 4 years ago. My team did it and we still talk to each other almost everyday even if we switched jobs. I think it's a good experience if everyone likes it. I don't think we actually ever did 8 hours straight of pair programming. Between pauses and meetings it was more 4 hours per day.

I also have a friend a Pivotal and what is described in this article doesn't sound at all like what he usually chats about.

I think that what the author is feeling cannot be result of pair programming alone. I have to say though that many people dismiss it without even trying like some of the comments on this thread sound like.

I want to see a documentary about Larry David working at such a cult company for a month.

Automatic material for two HBO seasons.

I worked at ThoughtWorks for three years, and -- like everything else XP -- pairing was very much the norm, for the software engineers, and I believe on the whole it worked to our benefit. I am off-the-chart introverted, so the forced intimacy aspect was a nightmare, but I balanced that emotional downside with the intellectual upside of learning a ton of things I might not have otherwise from the folks I paired with.

I've found pairing really useful for certain activities. If I'm working on very critical code or if I need to churn something vast out quite quickly, then pairing has served me well. As a new generation enters software I've noticed there's some differences, but it follows the same theme. Aside from pairing, they like to watch people code. Notably, I had a codebase that had been through a POC but lacked some E2E tests, so I streamed myself writing tests and refactoring code to make it more testable. The engineer picked up on the tools I was using, what I was doing, why I was doing it, and got to see me make mistakes. I think this is yet another avenue where we have opportunities to engage young devs and onboard them more quickly.

As someone that loves and suggests pairing, I'll pass on this:

- Never mandate pairing, authorize it. Some people really don't like pairing and will just complain endlessly.

- If you authorize pairing, find two people who are really good at it and have them train people on how to do it with your equipment and your environment.

- Personalities that clash on a team will predictably not pair well together.

As an introvert with a family needing random breaks through the day, if this became the standard I would immediately leave the software industry.

I paired at HMRC (the UK's IRS) for about four months. I quit when I was an anxious, depressed wreck who couldn't face going to work anymore. It was a completely soul destroying experience.

The emotional labour involved in managing colleagues (especially those who are less experienced) all day every day is so intense I could barely function outside of work. Steering people towards solutions when they were hung up on irrelevant stuff, explaining things to people who were themselves exhausted in the same way I was, remaining engaged when my screen share was hijacked yet again by someone who "just" wanted to show me something.

I have no idea how the author lasted so long. It took me less than 100 days of pairing (partly through a northern English winter) to quit.

Added to the above, the 'standard' Zoom caveats apply, too: https://www.bbc.com/worklife/article/20200421-why-zoom-video...

> 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.

I've paired for years, at two companies, but I have no personal sensation of "recovery capacity", because I'm an extrovert, and pairing gives me energy, instead of draining it away. One of my biggest complaints with my current company is that pairing is never done.

Extroversion is nothing but a neurological condition from birth.

Pairing is awesome for some, and torture for others.

Another benefit is the ability to work productively in the noisy Great Hall offices into which careless management and high office rents conspire to confine us. Instead of requiring the dead silence I need for solo concentration, I only need to be able to hear my pairing partner over the constant din of telephone calls, and reviews of last night's tacos, aisles away.

I was a Pivot - this article rings true. When I first joined people would often describe with joy how exhausted they were every single day for months when they first joined, as though it was evidence of learning and growth. That’s only true sometimes. What I realized is that it doesn’t actually stop being exhausting, people just adapt. There is a difference between being tired because I applied myself, did something meaningful and useful, and learned something new, compared to just being tired from navigating personal interactions all day every day.

It's a clickbait title, but he does also address the benefits of pairing. He does highlight the importance of not always pairing. He does not say not to pair.

I think what would alleviate most of his issues is having frequent breaks. 10 or 30 minutes here and there all day, or even an hour before resyncing is essential. Especially now with remote pairing.

I think opt-in pairing is bad. It essentially means, rarely pair apart from on hard things which is not pairing.

Opt-out is better. Then for some tasks you don't have to pair, whilst for most you do.

Or go full mob programming and allow people to come and go.

I joined a boutique software development consultancy where 90% time is spent doing pair programming. It works out well for them since they only take people who like the idea and process of it. I saw one guy leave after a short time because it wasn't for him and it's ok, this is why there is the probation period. The company has been successful here - our clients like us, they say we are the only partners they have had who actually deliver what they promise, etc

Pair programming is great! When you click with the person you're paired with. When you're with someone who you don't like/is defensive, it's terrible.

I used to work at a startup where I was the most senior engineer below one of the founders, a guy who happened to be remote, thousands of miles away, except about 2-4 times a year when he would fly in for a week or so and share my office with me. He was very enthusiastic about pair programming and we would do this for a couple of days every time he was in town, and afterwards would rave about how thrillingly productive it was. Except it wasn’t really true. I did really enjoy us putting our heads together and solving problems, and a day pairing really did feel more productive in absolute terms than what I would accomplish on my own, but more than twice as productive? Not a chance. More than twice as exhausting? Definitely. 4-8 days a year is about all I could take of that.

PS my theory about why he found it so invigorating and productive was that normally, he was too busy to ever spend an entire day writing code. He would be interrupted with meetings and questions all day. The difference when we were pairing was that he was “hiding out” for an entire day with his head in an IDE and shutting everything else out. I suspect he’d find it equally invigorating if he had the ability to do that on his own.

I had a great time pairing with a few individuals from my past, and I'd describe the sessions as playing a coop game with friends. It was fun to team up and figure out a problem and build something; the shared joy of overcoming some hurdle.

Similarly had good experiences 'mob' programming, 7 of us in a conference room focused on building out some new thing. But again, it felt more like hanging out with friends and playing a coop game together.

The game mentioned in the article, "Overcooked", actually caused my first and so far only visual migraine. It just completely stressed me out, forcing me to focus on an impossible task. Suddenly my vision looked like someone threw a wiimote into a TV.

I think pair programming is nice when cracking a tough nut of a problem or doing something highly safety-critical, but it's very taxing and there's no way I could do it all day long.

“Teams had half as many workstations as they had engineers.”

I've worked on teams historically that did pairing (even pairing all day), and mobbing all day, and I don't get the hate.

If the main issue is burnout, then what's up? Even working solo you can burn out, so I don't think that's a valid argument unless someone can convince me that specifically pairing is causing the burn out.

The biggest thing is you need a team that can trust and support each other.

Lots of people burn out. There's no reason presented to think the author would have had more, less, the same, or no burnout programming on their own. They happened to burn out, and they happened to be pair programming for an extended period of time. Myself and friends have also experienced burn out, and none of us pair programed any significant amount.

I've seen pair programming work when taken only in small doses - "Hey, look at this bug with me for 5-10 minutes" types of doses. It gives you another set of eyes, acts as one step better than rubber ducking, and quickly either gives help or confirms that no, you did not miss anything, so keep digging.

But more than that just isn't a style that works for me.

If your programming routine is causing someone to go on short term disability because it has caused them significant mental impairment, why was there never a discussion about perhaps too much of a good thing is now damaging our workers? Like, nobody thought to themselves, this is causing actual damage to our workers, and maybe we should scale it back?

This reads like my worst nightmare.

We do use pair programming to a limited extent: often in the context of a more experienced developer coaching a less experienced developer, or getting a couple of people working together on a particularly tricky problem, so I'm not entirely against it at all. As I said though, this post reads like hell to me.

I've often joked that techniques like pair programming are "software development for extroverts". I certainly didn't get into programming because I'm some sort of out of control social animal, and I was absolutely the stereotypical nerdy kid at school.

I still skew somewhat introverted and need time alone to recharge. What I've found as I've moved through my career is that the more oriented my job is around social interaction, the less I want to be sociable outside of work. Now, as an executive, it's all about the people, and I've dropped to 4 days/week so that I don't turn into a total hermit, shunning all social contact, outside of work. If I don't have a day completely alone at the weekend I really start to struggle. Similarly if my only social interaction comes via work I also struggle. I lose perspective, become tired and disengaged, my judgement and decision-making goes on the wonk: nothing good comes of it. But there's always a balance. I have so much social budget to spend, if you like, and if I spend it all at work I don't have anything left for outside of work (and vice versa) - I always need to find a healthy middle ground.

I am just one data point and I know full well it's different for different people, but I suppose this is one of the issues I find most frustrating about "pairing mandates" (and, yes, I have worked somewhere that had one): enforced pairing doesn't take into account the differences between people. I'm not advocating that we're all special snowflakes but, at the same time, software engineers in general aren't doing basic tasks that can be easily interchanged with different individuals - sometimes not even within their own teams - so it makes little sense to me to force everyone to work in a way, all the time, that a decent number are going to find detrimental.

Let me put it starkly: if I'm working full time as a software engineer and you force me to pair all the time then not only am I going to hate my job fairly quickly, but you are also very literally ruining the rest of my life. I don't want to come home from work completely exhausted with no energy to do anything else and no desire to see friends or family. Not OK. Not OK at all. This is obviously one very effective way to burn people out.

We're all human, and it's helpful for everyone if we can remember that when we're at work.

I'll confess my bias up front: pairing has never worked for me, and I really just can't write serious code unless I'm in my own head.

Having said that, let me now ask pairing proponents: can you give me a rough idea of what you believe the economics to be? Because from my perspective the two people working together on the same program need to deliver value twice as quickly as a solo programmer merely to break even. Based on what I've seen my median estimate for how much quicker things go is ballpark 1.25x, and then throw in some amortized benefit for knowledge transfer and camaraderie. But in my biased opinion find it a stretch that you even hit break-even with high probability.

So, I would love to hear from pairing proponents how they think about the development economics and the size of the win.

[Edit: Article is spot on]

In my experience, pairing works really well to deal with ambiguity, as in problem solving.

In my experience, management often mistakes ambiguity with uncertainty when allocating resources to a project or engagement. This results in terrible pairing experiences where you've been allocated to a project where your normal tech. stack simply doesn't apply. You're suddenly in the weeds learning a new language / framework / deployment-environment playing catch-up with your pair, while your pair is trying to burn-down the actual task/story at hand.

Yes, Software engineers should be willing to learn new things. But, No, I'm not willing to sacrifice the primary psychological safety of knowing "I'm qualified to do my job" just to keep a cadence.

Requirement to pair is discriminatory for neurodiverse people. I always quit a company when they forced me to pair. I don't mind from time to time, but often it ends being me doing all the work but sharing the reward with other person that contributed little.

I find pair programming a useful tool. It's great as patterns and practices are getting stood up on a team, for ramping new members, disseminating knowledge or for wrestling through novel code. As the article gets it, at can also be very emotionally draining so team members don't reach for enough on their own. As a lead, I regularly encourage or instruct my team to pair. However I also wouldn't make it an "always on" policy. It IS exhausting, and it is inefficient in many cases.

We've also adopted a few alternative practices (especially frequent "mob coding" sessions where we work through problems as an entire team rather than just pairs) that people find less draining.

Is it really true that Pivotal had only n/2 workstations for the n devs? That seems to be an extreme arrangement (pardon the pun). I can see the benefit of pairing when

(a) the problem is somewhat well-defined, and there is a natural 'end' to the exercise. For example, a P0 bug that needs fixing immediately, and there's not much time for additional code-review. In this situation, pairing with the person who knows the area well may be beneficial, because you get code-review while solving the problem. And your non-keyboarding partner can see things that you are too deep in to see.

(b) an interviewing technique to see how you collaborate and approach problem-solving (once again, there's an element of non-open-ended problem-solving here). I must hasten to add that this should not be the sole evaluation method in an interview, because many people can't collaborate impromptu with someone they do not know, and many people prefer to let their minds wander in search of a creative solution, which can look like cluelessness in an interview situation.

(c) inducting a new developer into a team: by watching a veteran at work and the techniques he uses, a new hire can quickly absorb best-practices that will bring his productivity to a high level in a relatively short time period. Once again, this must be done for shorter time-periods: it's pretty much impossible to maintain a high level of engagement with a problem for hours on end. Putting the problem in your back pocket, and sleeping on it often leads to flashes of insight that can deliver robust, clean code (the first system or solution to a problem is almost never the best, particularly in software or schema design).

I can't imagine many other scenarios outside of these, particularly for routine software development work, especially when code review by peers is a mandatory step in the process. You are probably removing the element of slow thinking, which can improve product considerably, by forcing pairing all day, every day.

How does such a wonky culture take root in a fairly large organization anyway? A lot of senior developers would just refuse to work for such an organization!

For people not that familiar with this particular development technique: he means pair programming. When I read "pairing", I think about Bluetooth devices first, which can be an ordeal sometimes, but hardly something that can lead to burnout...

I just can't do pair programming. I like doing my work, testing a bit and throwing it over to CI, QA, etc. Sorry, I'm just not that social, nor do I want to be in communication that often with any other human being other than my kids or wife.

Ouch. Another cult in action, just like Agile. What utter madness.

Pairing all day, every day is a relatively rare version of pair programming. In every case I’ve seen, pair programming was only done for a few hours a day or in select circumstances such as architecting a system.

Browsing the comments, that seems to agree with what most people have experienced at their jobs, with the exception of a few horror stories about companies that forced 8-hour per day pairing and paid the price for it.

I think it says a lot that there are 156 comments in this thread and introversion is only mentioned three times including this comment so far. More people need to take personality tests lol.

You can't operate indefinitely this way as an introvert, it's physically impossible. Extroverts simply can't comprehend how impossible this level of interaction on a daily basis is for an introvert. Programming is an inherently internal process which is introversion, and naturally draws people that lean more towards introversion to this field. I'm not dismissing the benefits of pairing, but to do it while completely ignoring the needs of the target audience (predominately introverts) is ludicrous and of course this burns people out.

Introverts, to varying degrees, expend energy in the presence of other people. They have to be alone to recharge. There is often a misunderstanding that introverts are just shy, this is a fundamental misunderstanding. Shyness often accompanies introversion but they are fundamentally different aspects.

Extroverts are the opposite, they gain energy when interacting with others. Most people are some form of omnivert, certain interactions can drain them and other interactions can give them energy.

No matter how beneficial pairing is it will fail if it doesn't learn to adapt more to the needs of the core user: introverts.

My experience is that it's best when it happens organically. Enforcing this sounds like a punishment.

As with almost everything, the truth is somewhere in the middle – pairing isn't universally good, nor univerally bad. It shouldn't be done all the time, neither should it never be used.

"There is no silver bullet." Fred Brooks wrote this over 30 years ago, and it still applies.

I sometimes coach new teams on pair programming and XP, so wrote this short article explaining how it works in practice, using snakes:

https://sonnet.io/posts/snakes/

It seems interesting but rather inefficient since you can just do things faster than explaining them to someone and having them do them.

It seems like it would only be good on tasks where having your partial work continuously reviewed is very valuable.

Humans are fundamentally meant to interact and collaborate with other humans. Technology has obscured this by empowering us each to be resourceful alone. In the long term, we indeed do operate best collaboratively.

Pairing is hard because it involves two or more brains trying to solve a complex problem live through mediocre sensory and speech motor systems.

Naturally it’s going to work fine for some and be disastrous for others.

Chiming to say that I too have burned out as a result of forced pairing. Will never do it again except on an ad-hoc, limited basis.

I feel like in 2021 I can roundly refuse to engage in pairing and question the experience of anyone suggesting it.

Pair programming was invented so consultant bodyshops can bill customers twice the price for half the mediocrity.

How did this person link the cause and effect?

How repeatable is this pattern?

How were the other possible reasons eliminated like aging, depression, and many other factors that also are happening in parallel during the course of 5+ yrs?

Correlation does not mean causation.

This story should be in the dictionary under "Cargo cult".

Shoot me now