Pair programming is where two programmers work together at a single computer. One writes the code, while the other observes and offers suggestions. Its often lauded as a key part of agile software development. I think it's terrible.

Let's start with the economics. Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense.

I'd argue that pair programming isn't only ineffective, but detrimental. Pair programmers tend to give feedback that's more appropriate in a design or code review. The overall strategy should be agreed to before you write any code. For the pairs that follow this, the only feedback that's left tends to be bikeshedding or stylistic, both of which kill velocity. It's like having a backseat driver. Not to mention the coveted flow state that most developers look for.

Pairs tend to devolve to least-common-denominator performance. Experts paired with novices need to move as slow as a novice. While pair programming might achieve some goals as a pedagogical tool, there are more time and cost efficient ways to share knowledge between team members.

Alternatives like code reviews, design reviews, and general documentation are much better 1-to-n ways to share knowledge instead of 1-to-1. In addition, most of these alternatives be done asynchronously. If you're looking to level up your code review process, check out my Ten Things I Look For In a Code Review.

Addendum: With the proliferation of CRDTs and Remote IDEs, maybe there's a future for collaboratively writing code. Maybe AI-powered code suggestions like GitHub Copilot play a role as well. Personally, I don't see Google Docs-like realtime collaboration on code can be that useful right now. But if it were effective, it would still have to look a lot different than Pair Programming does today.