Pair Programming Economics

- Pair programming works better remotely than people say, in my experience.

- It is a great way to share unwritten/unspoken information and best practices.

- PP is excellent for team cohesion and allowing engineers to get to know each other and their strengths.

- Not every engineering problem warrants PP.

- Some problems are better solved by one person as it can take too much time to get the other person up to speed with the issue.

- Pair programming often leads to better code, but you have to balance that with the overall reduced amount of work being done at once. If two people are working on one issue, you have to balance the benefit of that versus two people working on two problems.

- I'm more effective when I can focus, and sometimes I need to spend an hour deep-thinking about a subject and perhaps pseudocoding something. Pair programming with someone remotely and having long periods of silence would be... weird.

- People seem to view PP as a measure of success. The more a team is pairing, the more success being experienced. Right?

- If someone isn't into pair programming often, that's seen as a negative.

- 95% of people who pair remotely need better microphones or accoustic environments. I wish remote companies would ship their employees a pair of AirPods, a Yeti mic, and some acoustic foam squares.

- Pairing is more consistently useful for reviewing large code changes where it can be difficult for a reviewer to reason about the work that was done. Going through it with the author and doing a screen share can make all the difference.

My conclusion is that pair programming can be good for some things, but I would consider it a red flag if a company highly emphasizes pair programming or coerces people to do it. Treating pair programming like a panacea dismisses the fact that people of different personality types have been writing perfectly good software without pairing since time immemorial, and that there are other ways to improve code and product quality. What I think can be nearly as effective as pair programming is getting code reviewed early and often. I'm not the best at this yet, but I've noticed that life is just better when I don't do a ton of work and wait for it to be reviewed when it's "done".

My suspicion is that the jawboning about pair programming has more to do with the fact that it's a legal way to weed out older programmers than for any real economic benefits. We're more likely to have hearing loss, and will seem like poorer programmers in a pairing situation. Plus, we're overall less likely to put up with trendy bullshit like PP.

Not necessarily. I pair with a guy who's probably 10 times as productive as I am(I really try, but I understand that I'm relatively slow), and he'll ask me to pair with him because I might come up with an idea for something that even he is stuck on. I often do, despite the fact that I'm much slower than he is at implementing things.

So while I do think that it can often be the case that a pair will only work as fast as its slowest member, most likely when tackling a large problem or even doing something tedious, that doesn't mean that there aren't times where a more productive member can value from pairing with a less productive member.

EDIT: This is entirely from my point of view, so it's possible that this person I mentioned feels differently. However, even if they were frustrated by my slow performance, I don't think they'd inquire my assistance on problems if they thought they wouldn't benefit from it.