the thought of pair programming nearly gives me an anxiety attack. the second it’s mentioned in the interview process, it’s an automatic no from me. what other industry or domain does this? none that i know of.
first of all, working in pairs creates a problem when there’s disagreement. you need a group of three to five to find agreement in those cases. working in pairs also requires a very tight alignment of style in programming, thinking, speed, brainstorming, etc. it simply does not allow for moments of thoughtful rumination or experimentation. it’s just like having pairs in school. it never works unless the two people are copies of each other or both people have spent time doing and thinking about the task themselves independently beforehand.
i think working in pairs or small groups for design, review (or a post-review discussion), and especially debugging works quite well. it also works well when there’s a new person being ramped up or someone in the pair who is particularly knowledgeable about a portion of the interfacing code or sticky points. but two people sitting at a computer implementing? that only works for a very, very short amount of time, if at all.
i refuse to work for any place that forces this upon workers. it creates just another selection bias in interviews. engineers already look for people just like them, and this just adds to that bias.
and the articles for the benefits does nothing to say what pair programming does to actually enable the benefits listed. all of the benefits can be accomplished by shared design plus individual design, shared review, shared debugging, and individual implementation.