[ryanbrunner]

> I think ultimately, at the end of the day, I expect and hope that every human I work with is a competent, solid individual contributor and does not require a co-driver to produce meaningful work.

IMO this is a very wrong way to look at pairing. It's not about one person being incapable of delivering a solution on their own, it's that having multiple perspectives on the code will lead to a higher quality and more well designed product.

You could use the same argument you're using to say we shouldn't do code reviews, because we should trust that every developer is competent.

Also, at least in my experience, design isn't primarily or even mostly confined to an initial design phase. Most of the 'design' of a problem occurs when you're actually coding.

[vidarh]

My experience is that pairing is deeply disruptive to my exploration of a design. It forces me to slow down and verbalise something that I can clearly visualise in my mind, when the fastest way to externalise it for me is often to write the code and show it. I'm happy to walk people through a prototype afterwards and discuss it and if necessary throw the thing away and start over or significant revise it. I'm not happy to have someone disrupt my thinking about a problem while I'm trying to focus.

Fundamentally I tend to think that people who insist pairing is ok to impose on people think everyone is like them, and don't see that it's forcing out people with different ways of thinking and processing problems. Ultimately I think it's bordering on discriminatory in that it's selecting for extroverts who don't burn out by the extensive amount of interpersonal contact pairing forces rather than selecting for results.

For my part I will never work somewhere that imposes pairing. I'd rather leave software development altogether than suffer through that, because it's not worth the exhaustion and the reduction in throughput other than occasionally (e.g. while training someone or walking people through a prototype). Thankfully I have the luxury of not having to take that shit.

[whynotminot]

> My experience is that pairing is deeply disruptive to my exploration of a design.

I think it's one of those things where some people are good at it / enjoy it. Some people don't.

As a paradigm, I think pairing is better. Two talented, smart people who are able to work together will produce a better solution than one person alone. 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.

I've seen a lot of code over the years developed in silos by talented people. The work gets done. But the teams I've been on that embrace pairing produce better code, the team has better shared context, and there's a real joy to the work. This becomes disrupted when someone who does not like pairing joins the team, and actively resists the process, hoarding context and cowboy-ing solutions off on their own.

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

I think companies can perfectly well operate with lone wolf engineers. 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.

From my experience, it's just better. But hey, I'm biased. I'm one of those people that enjoy it.

[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. ;-)

[jdlshore]

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

[pydry]

Mine is the exact opposite. Slowing down and explaining design firstly helps to clarify things in my own mind and the pairer will usually see things that I missed as I explain.

I also find that getting stuck alone on a problem kicks me into a procrastination spiral whereas I tend to find it easier to push on when I'm stuck with someone. It also helps prevent me from getting into a spiral of second guessing every technical decision ive made in the last month.

I dont really think people take to pairing or not on the basis of its prima facie effectiveness though, but rather whether they enjoy programming as a solitary or social activity.

Really, I think teams should be set up to ensure people who like pairing to be together and vice versa, coz i feel just as miserable working alone all day every day as you do pairing.

[vidarh]

> Mine is the exact opposite. Slowing down and explaining design firstly helps to clarify things in my own mind and the pairer will usually see things that I missed as I explain.

I absolutely see value in explaining a design, and doing so with code, before you commit to the full project, but for me that step follows getting my initial design ideas down as code. I've had any number of projects where I've explained the high level design in words first, and people don't understand why it matters, and then I've put it down in code and shown the concrete benefits, and it instantly clicks. That doesn't mean that design will be set in stone and perfect, but I find it much easier to have the discussions about the design then.

But that's me. If you prefer writing the initial code as well with someone, you should by all means keep doing that.

> I dont really think people take to pairing or not on the basis of its prima facie effectiveness though, but rather whether they enjoy programming as a solitary or social activity.

I think you're right, with a caveat that it's not for me necessarily about not enjoying social aspects of it, but about the granularity of it. I'm happy to walk people through my code, but I want peace and quiet to put in place at least the outline of the design in solitude first.

> Really, I think teams should be set up to ensure people who like pairing to be together and vice versa, coz i feel just as miserable working alone all day every day as you do pairing.

That is absolutely reasonable. I have no issue with people pairing. I do have an issue with teams where becomes an expectation for everyone.

[gregkerzhner]

The crux of it is that pairing works for some but not for others. But often, it’s forced on everyone, usually from the top down. This is done in the name of vague benefits like “correctness” and “knowledge sharing”. Have these benifits even been confirmed through unbiased scientific studies?

The problem is that in the tech biz people tend to follow blindly without thinking. There was a point there where just because Pivotal Labs had some success pairing full time, everyone followed blindly. It’s the same with leetcode style interviews, open offices and ping pong tables - it worked for google and all of the sudden everyone is following blindly.

But personally, I wouldn’t work somewhere which paired heavily even if the benefits could be proved. I simply won’t do it because I don’t enjoy it!

Just like the choice to work remotely, the choice to not pair seems like a basic employee freedom that we should all have. Luckily, the way our industry is moving, such freedoms seem to be increasing.

[vidarh]

> Have these benifits even been confirmed through unbiased scientific studies?

Good question. The problem there is that setting up a study of this is rife with problems. E.g. ensuring you're comparing "like for like" developers is hard enough. I have no problems believing that companies like Pivotal that are known to do it get good results from it, for example, because by announcing it they're self-selecting for developers who at least believe they do better in pairs. That may well even be a decent strategy to prevent dead-weights from applying, and so I could also very well see them doing better than a company with poor screening and performance management.

> The problem is that in the tech biz people tend to follow blindly without thinking. There was a point there where just because Pivotal Labs had some success pairing full time, everyone followed blindly. It’s the same with leetcode style interviews, open offices and ping pong tables - it worked for google and all of the sudden everyone is following blindly.

Cargo-culting in other words...

> But personally, I wouldn’t work somewhere which paired heavily even if the benefits could be proved. I simply won’t do it because I don’t enjoy it!

Same here. I'm fine with others doing it, including on teams I run, but other than sessions to teach or communicate a design I'm unwilling to be forced into it.

[saulpw]

This are two modes, "explore" and "exploit". Solo thinking as you describe is usually best for exploring. Pairing is best for exploiting.

[vidarh]

Pairing doesn't work for me for either. It works fine in short bursts for knowledge sharing, but an understanding of a code base can be conveyed in small fractions of a time it takes to write it.

[almog]

Every word here.

Pairing was highly encouraged in my previous job. We did it for 5 or so years, even when working remotely using tmux. In my last 2 years there, in an attempt to increase throughput / save time, pairing became something you only do for crucial task.

I could argue that the code quality declined as well as the distribution of knowledge while not seeing significant increase in throughput of work done. Even more, and due to knowledge sharing, code review time increased.

I recently asked a friend who's a team lead at a FAANG company if and how they do pair programming. His answer was that it is not encouraged, mostly because "performance reviews assess contribution of individuals, and pairing would disrupt this process".

[bartread]

> it's that having multiple perspectives on the code will lead to a higher quality and more well designed product.

Will it though, when those multiple perspectives are enforced through pair programming?

Like a lot of agile cargo-culting, pair programming often seems like software development for extroverts. Those of us who are introverts, and got into software development because it's interesting work which suits our temperaments, don't necessarily appreciate this... at all. I'm not saying I'm unwilling to work with others, or figure out problems together - I have to do this all the time, we all do - but I prefer to program alone.

[steelframe]

> I prefer to program alone.

I think a developer has to earn that privilege. Often times developers use the "just let me do my own thing by myself" line to push code they know is crap, just because they don't get the same level of scrutiny and accountability through an asynchronous code review. Asynchronously, the code reviewer isn't easily able to see the author's thought processes as they constructed their code, so they don't really know whether the author's way of solving the problem is reasonable given the context without putting in significantly more effort into reading the entire context in which the change was written.

After having dealt with mountains and mountains of technical debt in my career, I'm firmly of the opinion that every developer should go through a period of pair programming with a more senior developer. Maybe they can do it for their first quarter with the company. At that point, if the senior developer signs off, they can acquire the right to code independently if they so desire.

[Veuxdo]

Who should decide this? Is it based on level? Degree?

[sidlls]

"IMO this is a very wrong way to look at pairing. It's not about one person being incapable of delivering a solution on their own, it's that having multiple perspectives on the code will lead to a higher quality and more well designed product."

That's what PRs are for. One can't use the same argument to oppose PRs, as you suggest, because of this key difference: in a PR, the person doing the review has (or ought to have) context on the broader picture (e.g. overall architecture, structure of the code in which the change is being made, etc.), but not the specific changes. It's analogous to having a proof reader: one doesn't invite a peer author to review his writings, because the peer has an implicit bias and can easily miss defects.

"Also, at least in my experience, design isn't primarily or even mostly confined to an initial design phase. Most of the 'design' of a problem occurs when you're actually coding."

This is common, unfortunately, and one of the primary reasons software is so buggy and overly complex. The code isn't the design, or shouldn't be. To draw an analogy to physical/industrial processes, the code is the machinery on the factory floor doing the work--the design is what was used as a blueprint to construct that machinery.

[slaymaker1907]

As the design evolves, this stuff should really be communicated to the rest of the team before the PR. The purpose of PRs should be almost entirely about finding bugs and typos.

[sidlls]

It should be, but another thing in this industry is the completely subjective design ideas everyone brings. So PRs inevitably have comments about the approach to abstractions, testing, etc. that are really little more than ego-stroking.

[ParetoOptimal]

What are "draft PRs" for then?

[slaymaker1907]

If you mean what I think you mean, those are one of the few exceptions. I assume you mean just implementing the feature/bugfix quickly because it helps with the design discussion. Even in that case, I think it's a good idea to have a final non-draft PR (or just have people look at it again with fresh eyes once out of the draft stage) where the main goal is just to verify correctness.

[moron4hire]

Nah, it's about management weaponizing coworkers against each other to make sure nobody is "goofing off".