[vidarh]

> Two talented, smart people who are able to work together will produce a better solution than one person alone.

The issue I have with this statement is that working together does not require pairing. I agree with your statement, but not as support for pair programming.

> As you rotate pairs, context on the code base is shared and permeates the team faster. New onboards get up to speed at a remarkable pace--far better than the "uhhh so checkout the code. Mess around, see if you can get things running. Idk good luck" process I usually see on non-pairing teams.

None of this requires pairing to address. I do address this by sitting down with people and walking through code, to give an overview or when people have a concrete problem. A big problem I see with pairing in this context is that it promotes not learning how to learn from code. I see this often when I'm brought in to troubleshoot code with developers who look like deer in headlights when they are dealing with something out of the ordinary, because they've learned the hot spots of the code rather than actually reading through and understanding the conceptual basis of the system and the design behind it.

> If I ever run a company, I will select for engineers who aren't just comfortable with pairing, but actively enjoy it.

Having run companies, and hired many dozens of engineers, if you do so you'll end actively discriminating against many types of neuro-divergent people. Apart from the issue of whether or not you can actually show any benefits, you'll be one little conflict away from a lawsuit.

> I think companies can perfectly well operate with lone wolf engineers.

This is a false dichotomy. Nobody here has argued for "lone wolf engineers" as far as I can see.

> But you have to add a lot of process to wrap that mentality--code reviews, design sessions, context share-outs, multiple people singing off on PRs. These are things you can largely do away with if you're doing pairing correctly.

If you do away with those things just because you're pairing, you're setting yourself up for massive risks and failures.

[jdlshore]

> one little conflict away from a lawsuit

I find this hard to believe. Which country’s laws are you thinking of? In the US, at least, companies such as Pivotal and Menlo Innovations, as well as others I’m not at liberty to name, require full-time pairing. They’ve never had an issue. Your statement is also at odds with my understanding of employment law, which is admittedly at a layman’s level, but I have studied it for the purpose of hiring in Oregon.

> setting yourself up for massive risks and failures

You’re losing credibility with me. I’ve done exactly what GP is talking about and it was better than code reviews (etc), not worse. Are you talking from experience, or from personal preference?

[vidarh]

> I find this hard to believe. Which country’s laws are you thinking of? In the US, at least, companies such as Pivotal and Menlo Innovations, as well as others I’m not at liberty to name, require full-time pairing. They’ve never had an issue. Your statement is also at odds with my understanding of employment law, which is admittedly at a layman’s level, but I have studied it for the purpose of hiring in Oregon.

I'm in Europe, but I've seen such law suits and threats of lawsuits over issues like this affect companies I've done projects for first hand, including at least one US company. They are very hard to make stick, because most people are not dumb enough to make statements that are clear cut enough to provide proof that the employees failure to get hired is discrimination. But that does not stop people from suing (or threatening to sue). I've seen team paralysed for months [dealing with legal issues surrounding conflicts over discriminatory hiring practices] instead of doing their jobs. I've also personally seen people walk away from threatening lawsuits over issues like this with well over a years worth of compensation just from a threat.

This is separate from the moral issue - personally I've interviewed enough neuro-divergent candidates who were qualified (and hired a few) but who'd struggle with things like pairing and I'm personally not willing to refuse to make reasonable accommodations.

> You’re losing credibility with me. I’ve done exactly what GP is talking about and it was better than code reviews (etc), not worse. Are you talking from experience, or from personal preference?

I'm talking from experience over nearly 3 decades, including direct personal experience in cleaning up the failures of teams who took short cuts because they thought pairing could replace code reviews. They catch different things. Pairing for some teams where people are comfortable with it leads to lower counts of some types of defects assuming a lot of things go right (e.g. the pairs are matched well with people who'll actually speak up and challenge each other), but pairs tends to look themselves blind to many of the same categories of failures as individual developers because they focus on solving a task and steer their view of the code accordingly rather than looking for at breaking it.

It's the same reason developer written test suites does not obviate the need for QA, and internal security reviews does not obviate the need for external pen testers, or having developers try to think about operational issues does not remove the need for SRE's or equivalent.

[whynotminot]

> Having run companies, and hired many dozens of engineers, if you do so you'll end actively discriminating against many types of neuro-divergent people. Apart from the issue of whether or not you can actually show any benefits, you'll be one little conflict away from a lawsuit.

"We pair program here--that means actively working with another engineer for 8 hours a day. Is this something you're comfortable with?"

"No. But knowing this, I am going to still pursue this job. I will then sue you when I'm unhappy with the requirements you've clearly outlined to me."

What a world.

[vidarh]

> What a world.

A whole lot of unwillingness to make reasonable accommodations for people based on disabilities will open you up to lawsuits.

To imply reasonable accommodations for neuro-divergent people is simply a matter of "comfort" is indeed worth a "what a world" on the same level as refusing to make reasonable accommodations for those who are blind or hard of hearing or in a wheelchair.

[whynotminot]

> A whole lot of unwillingness to make reasonable accommodations for people based on disabilities will open you up to lawsuits.

I kind of take issue with your assumption that someone with (edit: meant Neurodivergent... NPD is something else) can't pair program.

If your assumption of an effective pair programmer is that they're always bubbly extroverts with politician-level shmoozing capability, I kind of doubt you've spent any length of time doing it.

There's a lot of people who struggle with more "normal" communication that are incredible pair programmers. I've worked with many of them. In many cases, the code and the keyboard becomes a communication medium they're effective at leveraging--more than other means. Actually doing pair programming challenged a lot of my misconceptions about what it takes to be good at it.

It's skill and like any other should be disconnected from stereotypes. I don't see why you can't hire for it like any other. Hopefully I don't run into you in the court room. ;-)

[vidarh]

> I kind of take issue with your assumption that someone with NPD can't pair program.

Many can. Many can't. I did not make the assumption you're arguing against here.

> If your assumption of an effective pair programmer is that they're always bubbly extroverts with politician-level shmoozing capability, I kind of doubt you've spent any length of time doing it.

That was not my assumption at all. You're jumping to unwarranted conclusions not at all supported by what I wrote.

> There's a lot of people who struggle with more "normal" communication that are incredible pair programmers.

That's fine, but it does not change the fact that many people struggle with it. Including people who manage to deal with "normal" communication just fine, but who find the intensity of a pairing unbearable. I can do it, but to me it is intensely uncomfortable to the point that as I've pointed out elsewhere I refuse to be pushed into it - for me it's not a problem, as my career has afforded me the luxury of picking and choosing positions where I get to decide what goes -, but I've met many brilliant developers over the years who just could not deal with situations like that at all.

> It's skill and like any other should be disconnected from stereotypes.

This dismissal of what to quite a few people is an inherent part of their neurological makeup as a "skill" comes across to me as incredibly offensive.

[whynotminot]

> That's fine, but it does not change the fact that many people struggle with it. Including people who manage to deal with "normal" communication just fine, but who find the intensity of a pairing unbearable. I can do it, but to me it is intensely uncomfortable to the point that as I've pointed out elsewhere I refuse to be pushed into it - for me it's not a problem, as my career has afforded me the luxury of picking and choosing positions where I get to decide what goes -, but I've met many brilliant developers over the years who just could not deal with situations like that at all.

I'm not disagreeing that some people don't find it enjoyable, and some people aren't good at it. Like anything else.

I don't see why you just wouldn't work at another company instead of demanding the company change its methodologies for you. I'd say the average dev shop leans more "lone wolf" anyway. Teams and especially companies that pair are the exception, not the norm. You're an experienced guy it seems like--I'm sure you've changed jobs many times in the past to find a culture and working conditions that suited you better.

> This dismissal of what to quite a few people is an inherent part of their neurological makeup as a "skill" comes across to me as incredibly offensive.

I'm sorry my view on this offensive to you. I don't mean to offend you, but simply stating you're offended doesn't change my perspective--I still view pair programming as a skill, and I don't think it's wrong to hire for skills.

[vidarh]

> I'm not disagreeing that some people don't find it enjoyable, and some people aren't good at it. Like anything else.

I'm not saying that some people don't find it enjoyable. I'm saying that some people can't do it without risking their health.

> I don't see why you just wouldn't work at another company instead of demanding the company change its methodologies for you.

Most people do, or end up unemployed. This is a widespread problem with the lack of protection of employment opportunities for differently abled, and a reason why I find it immoral to refuse to make reasonable accommodations based on it, the same way I'd rather walk from a job than e.g. refuse to hire someone just because they're blind or deaf. That a whole lot of companies do just fine without pair programming, to me is clear evidence that it's a reasonable accommodation.

> I'd say the average dev shop leans more "lone wolf" anyway.

Either we have very different ideas about what "lone wolf" implies, or I deeply disagree with this. But in terms of not mandating pair programming, sure. I don't see that as an indicator of people being "lone wolf" type programmers, however.

But the existence of less discriminatory environments is not a justification for accepting discrimination.

Note that I have no issue with companies choosing to prefer pair programming. It's their business, though I'd probably still not want to work there (and that's my business). What I do have an issue with are those who outright demand it of everyone and are unwilling to make adjustments.

[gregkerzhner]

Ultimately, I file (mandatory, full time) pairing in the same category as mandatory in-office work, meant to encourage brilliance from random water cooler interactions.

In a perfect world, is a fully engaged in-office employee better than a remote one? I’d say probably yes. In the real world, is a disgruntled, commute tired employee better than a happy remote one? Unknown.

Same with paring. If your team is full of perfectly interchangeable humans drinking the same cool aid, then pairing sounds great. But real humans don’t work like that, and for every person who is boosted by pairing there may be another who is held back by it.

In the end, it’s likely best to allow employees to self select the mode of work which works best for them (location, pairing amount, computer choice) so that they are happy and productive. Any kind of top down mandatory policy on those choices will inevitably be worse than each person’s preferred choice.

[jdlshore]

It’s not the world, it’s GPs fantasy.