Bonus, a third advantage: Your team would tend to favour pair programming. For the simple reason that you wouldn’t have pull/merge requests.
I gave you this statement at the end of last week’s email.
Confession: I don’t particularly like pair programming.
I like to talk with people and think things through, together with others. But I do like to implement in solitude. In smalls steps with frequent reviews. Actively pairing drains my energy just too much.
But it makes the list of disadvantages just as well.
- For effective spreading of knowledge you have to use pair programming.
There are no formal reviews like pull requests. Tests get you so far, but knowledge about the code needs to be spread across your team. You shouldn’t depend on one person for a given module.
- It can be really stressful.
Admittedly, this is only my personal point of view. Always committing on master with good tests keeps you on your toes. Which is good. It just means, that the rest of the work and work environment has to be designed in a way that high-intensity work is possible. I haven’t seen a place like that yet. (Sorry Philip)
- You’ll need buy-in from everyone.
Your whole development process needs to be supportive of this. How you develop features, how you deploy these to clients(?), how your QA department tests etc. I am probably forgetting a few things.