[epolanski]

I have recently switched teams and I'm in one where most programming but trivial tasks are done in pair. I can see lots of pros and few cons:

- knowledge sharing, especially business, domain, old code, etc. The biggest stopper in writing software in large organizations is rarely technical difficulty but context

- focus. If I'm alone I get distracted much more, music, youtube, socials, I know this is on me, but getting distracted while pairing is hard and rude. I'm also much more organized and a coworker is much better than a rubber duck.

cons:

- you are blocked from working if a coworkers schedule is not aligned

Overall I think pair programming makes in my, and most organizations produce more work than if the contributors where solo programming.

[eikenberry]

> Overall I think pair programming makes in my, and most organizations produce more work than if the contributors where solo programming.

I think this is the key takeaway with one missed point. IMO it definitely does produce more work vs. solo programming but that work is sub-par. The necessary time isn't spent thinking on the tasks but instead the pairing rushing things through with very little thought to design and long term maintainability.

[gregkerzhner]

The part of my brain which thinks deeply and produces elegant solutions simply shuts down when I constantly have to explain my thought process to someone else. I actually have the same problem in pair programming interviews - my brain tends to freeze up and comes up with strange, hacky workarounds at best.

Later, when I’m alone and can focus the proper answer usually comes to me. I know there are others like me who produce their best work when they can focus, alone.

If pairing works for you, then that’s great, but it needs to be consensual and optional.

The problem with pairing is that it tends to be championed and enforced by more social workers (especially managers), and forced on the less social ones, who are often not in a position to refuse.

[RHSeeger]

> If pairing works for you, then that’s great, but it needs to be consensual and optional.

This is the key in my mind. Pair programming doesn't work for me, based on past experience. Pair design works great, and rubber ducking into a slack channel (that people expect that kind of thing to be in); those are things I find highly useful. But when it comes time to actually write code, I tend to work best alone.

I think part of the reason for this is that I tend to work through designs and possible implementations in my head, but by writing code. Then I'll discuss those designs to come up with some possible issues (pros/cons/etc). Then I'll work on implementing what seems likely to be the best choice (which is may not be once coding starts). By the time I get to coding, most of the impact of someone else being involved is just going to be catching typos. Or possibly code written in a hard to maintain way... but code reviews will catch that just as well (probably more so, because the person reviewing it _wasn't_ there when it was written).

[ParetoOptimal]

> Later, when I’m alone and can focus the proper answer usually comes to me. I know there are others like me who produce their best work when they can focus, alone.

Yeah, I've taken "thinking breaks" during pair sessions for this reason.

[Chris_Newton]

The necessary time isn't spent thinking on the tasks but instead the pairing rushing things through with very little thought to design and long term maintainability.

Indeed, and this is a problem that can affect other “Agile” practices too. Mandatory/permanent pairing is one example. TDD is another. Both can reflect a more general trend to try to break development down into tiny steps.

It’s not that there is no value in developers working together in real time, or in unit tests, or in incremental development and short feedback loops. All of these can be very useful. In my experience, they are often adopted spontaneously by developers even if there is no formal process in place that requires them.

But it’s also important to look at the big picture. You need a coherent vision for the product. You need a consistent domain model that is well understood and shared by both developers and non-developers. You need a reasonable software architecture that provides useful patterns and abstractions but also isn’t afraid to change them as requirements evolve.

Without these things, it’s easy to take a lot of small steps and create an illusion of progress, yet not move efficiently towards your true goal. Increasingly serious problems tend to get shoved under the carpet (sorry, “added to the backlog” or “labelled as tech debt”) until inevitably quality and productivity start to suffer.

You can’t fix those kinds of problems working in the small with only one or two participants.

[epolanski]

> The necessary time isn't spent thinking on the tasks but instead the pairing rushing things through with very little thought to design and long term maintainability.

I know it's anecdotal but this doesn't happen in my team. Our pairing culture isn't oriented at producing more but higher quality code, and it generally tends to achieve both.

Or, to turn it around, rushing tasks doesn't seem to be an issue of solo vs pair or mob programming.

[ParetoOptimal]

> The necessary time isn't spent thinking on the tasks but instead the pairing rushing things through with very little thought to design and long term maintainability.

I feel like pairing pushes people towards this because both parties feel the need to show they aren't "wasting time" by engines reasonable definition of it.

If you swim upstream and try to work against this, it can cause some friction.

[blindmute]

Con: almost no one likes doing this and you'll bleed talent

Con: you're spending literally double on engineers for the same amount of work done