I find pair programming is useful for overcoming a specific problem, after which you have to disband and each go off on your own. Examples:
- The problem can be that programmer A is stuck on a piece of code or debugging: this is usually part of a bigger task which A has as the top thing in their mind, but for some reason can't make progress. Programmer B brings a fresh pair of eyes to the table, but looking at it alone makes no sense, because their mental model will be up and running much faster with A's help.
- Onboarding. Programmer B is new to the project and programmer A gives an increasingly hands-on crash course of the project workflow and B's first task.
- The high-level parts of major refactorings. Neither A nor B will have the whole existing structure of the code completely in their heads, but between them they have a more complete picture and stand a much better chance of not messing it up.
None of these should take more than a few hours, or maybe a day max, or you probably will go insane, yes. It probably also depends on personality, but you should hopefully not have any homicidal tendencies after just a few hours.
FWIW, I agree with you about code reviews. I'd add that I've found in-person code reviews to be the most helpful from a communication point of view. For remote teams I suspect live screen sharing with audio is a reasonable substitute. I guess the downside compared to a formal annotated code review is that the latter is a kind of documentation. Not that I've ever referred back to one, but it's conceivable.
This is a good insight. Pair programming is a tool that is very useful in some contexts but not in others.
There are so many things that can vary from project to project: How big is the system? What level of expertise does each developer have with the domain, or with the tools being used to build it? What are the personalities of all the people involved? Is the system a cutting edge research project or a well understood thing that just doesn't happen to exist yet?
All of these variables, and lots more, would influence my decisions about who I'd want to work with, and (if there is someone other than me) how we'd work together.
Given all that I consider it extremely unlikely that there are any useful and universal conclusions to be drawn.
- The problem can be that programmer A is stuck on a piece of code or debugging: this is usually part of a bigger task which A has as the top thing in their mind, but for some reason can't make progress. Programmer B brings a fresh pair of eyes to the table, but looking at it alone makes no sense, because their mental model will be up and running much faster with A's help.
- Onboarding. Programmer B is new to the project and programmer A gives an increasingly hands-on crash course of the project workflow and B's first task.
- The high-level parts of major refactorings. Neither A nor B will have the whole existing structure of the code completely in their heads, but between them they have a more complete picture and stand a much better chance of not messing it up.
None of these should take more than a few hours, or maybe a day max, or you probably will go insane, yes. It probably also depends on personality, but you should hopefully not have any homicidal tendencies after just a few hours.