The good, is what the author was talking about. That team cohesiveness, that he disturbingly compared to being in a Borg Collective, is something that can't be easily quantified, but can amplify energy and positive morale. The Marines have known this for a couple of hundred years. Every Marine I've ever talked to, has described, almost verbatim, what he said. About how the squads act as a unit; almost without thinking. The results are tough to argue with. They are a highly effective fighting force.

The price can be burnout (as mentioned). When everything we do is being channeled and amplified, we have to be "on" all the time. We don't get that "five minutes of spacing out" between modules. In my case, that's absolutely required.

It's also a young person's game (like being a Marine infantryman). As I've gotten older, my personal process has become almost supernatural, but it has also become incredibly draining, and that "down time" is now no longer a luxury, but a necessity. On days that I have had some really challenging work, like chasing a pernicious bug, or setting up scaffolding for a new architecture, I can be absolutely flattened by bedtime. I feel as if I have spent the day digging trenches.

Also, I work best in my own head. I can create a pretty sizable architecture in my head, and don't need to write down a thing. That makes for very fast development, and tremendous flexibility. I can tear down an entire architectural construct, if it proves ineffective, and rebuild it, in a few minutes (in my head).

The minute I need to communicate it, however, that efficiency goes right into the bog.

Team work is much more natural if you are up against an external enemy in the broadest sense, like the military, farming, building an aircraft or a group of physicists taming nature.

It does NOT work for creative endeavours with a) a distinct amount of self-expression like programming or writing novels that b) also require enormous amounts of context in the working memory. This is why developers get into fights that easily.

(Please don't counter with "the humble programmer" and all that; we know, and Dijkstra himself wasn't humble. )

As long as everyone is "on the same wavelength" (I am sorry, I cannot quantify that better), it is basically effortless. You need someone to chop onions, and a few minutes later, they're just there. You sense that someone needs a filleting knife (they're just about to place a fish on a cutting board, or something similar that signals "this is the next tool needed") and you're close to it, so you make sure it is there for them (handle first, of course).

It is a very similar feeling to a well-integrated infantry unit making an entry into a presumed-hostile building, minus all the adrenaline.

This is why I've always found it frightening when some management type starts talking about the book Extreme Ownership. I am a veteran, though I was not SOF, and I have strong opinions about why military management mindsets do not translate well to the business world in _most_ cases. To be fair, I have not read the book, but from what I have heard from those who have read it, I would be wary of anyone trying to apply it to a software engineering shop.

The book is mostly about dealing with people rather than about engineering process, and I think the people aspects of a coding team and any other high performance team probably have a lot in common.

Both have completely different problems and advantages. The different (often complementary) tasks make all the difference here.

As a manager, I'm always on the look-out for tasks where I feel pairing may provide value. These are often moderately complicated tasks where I want a more junior team-member involved. Or, doing green-field UI work, I'll suggest one of the more UX-savvy developers pair with a small group of developers.

I have also managed people who just like to work together and they're free to pair and unpair on an ad-hoc basis. I don't care, as long as progress is being made.

Edit - I've never "paired" in the way you suggest in a sibling response (assigning a ticket to 2 developers).

Is collaboration / pairing part of employee evaluation in any way?

I'm not a vet (but my parents are planted in Arlington), but I've spent most of my adult life surrounded by them, so I've heard a lot of stories, and they are very practical, pithy applicable stories.

They often spring to mind, when I think about my work.

And we developers may not be thinking in military terms, but the chances are better than even, that the Corner Office is trying on a jacket covered in medals.

There is this study here - https://www.researchgate.net/publication/222408325_The_effec...

"A more detailed examination of the evidence suggests that pair programming is faster than solo programming when programming task complexity is low and yields code solutions of higher quality when task complexity is high."

There are links to a few more here - https://tuple.app/pair-programming-guide/scientific-research... - none of it looks particularly compelling.

And I'm not "against" pair programming. It's just sad to see "cargo cult" adoption of practices.

The worry for me is that there is almost always an obvious detachment from the steps carried out to the benefit which is the precise definition of a cargo cult. A lot of people can't seem to see this at all and when asked for some sort of rational proof, something I do regularly, tend to switch to a personal or ideological attack instead.

It's slightly tiring to be fighting the front of rationalism in an industry which appears to be driven partially by fashion.

As for pair programming, 100% anecdotally I find that sometimes you need a second set of eyes on a problem when you can't see the forest for the trees. But mostly it's inefficient and unproductive and absolutely crippling for small teams.

Rubber ducking is great for forcing yourself to articulate your train of thought, spelling out your assumptions, and proof-reading your own logic.

Code reviews are great for catching errors you glaze over because you're too familiar with what you think you wrote to see what's actually written. It's also a great way to onboard people and enforce code standards and best practices.

Even when you're in a more senior position code reviews can often teach you new things, when you interact with systems the reviewer knows better and they happen to know a better approach.

At my previous job reviews were required before you were allowed to check in, meaning if it wasn't good enough you had to rework it. This meant junior engineers were quickly brought up to speed with code convention and best practices. If you didn't adhere to them your code wasn't approved.

I also found it a great way to catch subtle bugs or difficult to follow logic. But it does require actually having and taking the time to carefully review things, rather than giving them a passing glance.

I've had great success with breaking larger changes into smaller PRs that get code-review-merged into an integration branch. Then the integration branch gets merged to your main branch once everything's done and verified.

But if that fails, it is definitely better to review and catch it after the code is written than to submit badly written code out of fear of wasted effort. In my experience the vast majority of tasks are easily addressed by a single person and most proficient programmers will usually produce perfectly adequate code which doesn't raise any concerns. Having reviews to catch the odd lapse in judgement or logical misstep doesn't usually add a lot of overhead (as opposed to allocating two programmers to every menial task) but saves a lot more time and effort in avoided bugs and issues than the cost of having to rewrite something every now and then.

Additionally, any single submit should be kept to a manageable size so that they're easier to review and issues are caught early. The only times I can remember having insisted someone rewrite something non-trivial have been when they misunderstood some fundamental issue, did not communicate progress as they should have, and did not follow guidelines of solving a single task per submit. That type of behaviour is in itself a pattern which needs to be addressed.

Yes, without a doubt.

> Having reviews to catch the odd lapse in judgement or logical misstep doesn't usually add a lot of overhead (as opposed to allocating two programmers to every menial task)

Having paired for years, and soloed for years, I have found that the downsides of allocation are overridden by the benefits of pairing, one of which is real-time code review.

In some cases it's invaluable, absolutely. I just don't think that's a large percentage of the code written on a daily basis. For most tasks pairing seems to be either

1) one person tapping out simple code which practically writes itself while the other lazily nods along.

2) One person solving something tricky which happens to be their area of expertise while the other stares blankly. Maybe at that point it would be useful to explain things in detail, but that can make development take much longer and if something like this requires rethinking halfway it can be quite taxing. In that case, I would prefer waiting until it's done and compiling the result as an annotated review. Which can be a great forum for asking questions.

As I alluded to earlier, I've never encountered these sorts of problems in the healthy companies I've worked at (but I HAVE encountered them at unhealthy companies).

Another problem I've observed in code reviews is that they turn into impromptu redesigning sessions. Most devs are quite opinionated, and code reviews often become an avenue to engage in bikeshedding that can actually harm morale, not to mention velocity and product quality.

The trouble with pairing is that it doesn't remedy these problems effectively, while simultaneously reducing the number of hands doing work. If two people just don't get along, pairing them is not going to magically solve the problem. And I guarantee that there will always be people who simply do not see eye to eye on many important things in most sizable teams.

The way to propose a change, in a "good way" (I am assuming here that no one has unilateral capability of merging to master, and things thus have to pass through review), to my mind, involve doing a few things.

<ul> <li> keep the change small ("small" here is a very fungible quality, but "probably less than n * 1000 lines") <li> does NOT mix "fix bug" / "add feature" / "refactor" (arguably, there are cases where feature-adding and bug fixing are instrinsically linked, let those through) <li> has a change description detailing the why of the change (the "what" is the change itself) </ul>

As a reviewer, your task is not to critique the design (that is why everyone agreed on a design doc up front, no?). It is OK to review the structure of the code, though.

Hopefully, you have a "run this through a linter / style-checker" integrated into your pipeline, so that should be pretty much already done. But, if there are a few things left over, it is OK to point those out.

It is OK to point out that things that should be (but aren't) tested should have tests. If you can spot an edge case that isn't (or doesn't seem to be) tested, ask for that to be tested, also.

People need to be permitted to take the time to do a review.

With these things in place, a review should be pretty quick (at the pace of up to a few lines per second), and most of the time frictionless. But, it does require some discipline, both from the writer and the reviewer.

It seems like there is something about pairing though that guarantees a focus on shallow insignificance. I don't like dismissing something that has smart proponents but I just can't find a way to make pair programming anything other than negative. The real time aspect rules out depth.

Yeah, it's a dangerous mindset, and I don't really know how to get out of it, especially since we're all hypocrites to some degree.

At ThoughtWorks we do promote pairing, please let me know if there is anything I can do to help you out!

Aka - Bob built a system using tooling that is new to our team and unknown to anyone else. Bob needs to pair with Fred for a couple of hours so more than just Bob will have hands on experience with the tech.

That’s my only requirement because in my experience it’s better than documentation and it’s a requirement to make sure Bob can take vacations.

Everybody will be able to figure it out eventually, but if something is urgent we don’t have until eventually.

The most progressive view I've seen so far in the "official" dogma of pairing says to accept people who work better outside of pairing, but to exclude them from important projects. I'm at a loss as to how this is a good thing, and to me is a sign of pairing becoming a religion of extreme bigotry.

Thank you for saying something that should be common sense! Don't expect everyone to work and think in the exact same way!

Yeah, the title suggests an anti-pair-programming rant, but the author seems to have stockholm-syndrome'd himself into accepting it. I tried pair programming once, a long time ago, when it first "came out". We immediately ran into all sorts of practical issues like, how do you check your e-mail? (Back then, you had to read e-mail in a dedicated e-mail client like Outlook). What if there's documentation that needs to be read? Take turns reading a page? I can't even conjure up a world where pair programming is effective in my imagination.

The pairing sessions were shared via ScreenHero (now I use Tuple), where each person has independent control of their own mouse cursor, but can grab control by clicking anywhere and typing.

Because the pairing session is constrained to the external monitors and the laptop screen isn't shared, each dev can still check their private email or look up things off to the side, but can also keep an eye on the pairing session and jump back in whenever they are needed.

This methodology works well in a side-by-side pairing environment, and it also works great for remote pairing.

If terminal based pair programming doesn't work, Visual Studio Code has an interesting "Live Share" feature which works similarly. You keep some of your extensions (and don't even need all of the same extensions installed to make things work depending on who shares).

I have yet to try it out though.

You don’t. That’s what breaks are for (assuming personal e-mail).

> What if there's documentation that needs to be read?

- Define an objective together (e.g. „We‘d like to understand how the HTML progress element works“)

- Optionally, agree an a timeout

- Split (both reading at their own pace, on their own device)

- Join and discuss results

"Bloing!" -- "Oh look, I think I need to read that email now." -- "OK, I'll toodle over to my own desk and see if I've got any. See you in five."

A computer isn't a hip.

For me the issue wasn't just the difference in frequency or duration of breaks, but also the fact that different people prefer to take breaks at different times.

In the end, unless you're very lucky, it ends up being a compromise for both parts and the productivity gains are negated by the constant context switching.

That is, the parent point, should not be used as an argument against there existing teams with team-level pairing standards or expectations.

If we get to the point where it is hard to find a non-pairing team, then maybe we revisit this. But given the diversity of people on this topic, that seems extremely unlikely.

The justification on teams that require pairing should be a non-judgmental "that's just how we do it here. For now." And people who have strong preferences should be able to ask about it interviews.

Sure, once the person is comfortable (and the "expert" is comfortable that they aren't going to do anything that they'll have to undo later) we typically go off and work on our own, but I just don't see how you can train others efficiently without pairing.

The important part is that they read the docs (as a sanity check that the docs still make sense to a newcomer) and perform the actions themselves. I don't touch the keyboard except when it's a complicated, exceptional issue that they're not expected to deal with at this level.

The other important part is that they update the documentation.

But it was always occasional, and short. Sometimes longer or more often if it's someone I really like to work with, but there have been only a handful in about 20 years of career.

I think that the biggest mistake about pair programming is about forcing it, especially when do it all day. I could never do that!

Beyond that, as a general rule it's only attractive to very mediocre engineers (who are honest enough to admit they need help).

In interviews for experienced roles, I might ask "what do you think of pair programming", and if they're positive about it there's a good chance I'll pass.

"Thing I don't like is only useful to developers who are worse than me" is a super toxic take. If you said something like that when I was interviewing you, regardless of how much pairing the company I'm running the interview for does, I'd pass on you as well.

This is a feature, not a bug!

Most people are mediocre at nearly everything. The mediocre person who knows their limitations and embraces systems to get the most out of themselves is more valuable than the mediocre person who sees themselves as a rockstar.