My experience pair programming: - Pair programming works better remotely than people say, in my experience. - It is a great way to share unwritten/unspoken in

My experience pair programming: - 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".