I was on a team for 2.5 years where pair programming was our default—we did it all the time and the only time someone solo’d was when there were an uneven number of us. I enjoyed it immensely and found it mostly positive. It was far more about de-siloing, creating a shared style, and bonding than it was about mentoring. People paired up regardless of level and we actually switched pairs daily. This means that if a story took three days to complete then the two people who started it weren’t the same two people who finished it. This was rough to get used to but once we did it was great.

Also as mentioned, “pairing” in our definition didn’t mean you couldn’t decide to break off and think through things on your own for a bit. We actually wouldn’t do that too often but when we did we would still pair off each morning. This gives you a dedicated point of contact for the day.

Some of the downsides have been mentioned. One particular one for sure is that it’s exhausting, but I found it to be a good kind of exhausting. And of course, if you don’t get along with your teammates then it can’t work. You also have to be pretty mature about being able to reach quick consensus (ie, get really good at “disagree and commit”, which is a key skill to have even outside of pairing).

I see the big positives as de-siloing and shared ownership. There was no code that “belonged” to anyone. No one ever said, “I don’t want to touch that because it’s so-and-so’s code”. Also, no one was afraid to go on vacation because at least three people had fairly intimate knowledge of each part of the system.

Also in my experience pairing is faster than soloing. Again, this is something that is only true if you’ve developed a rapport with and trust your team members. When you get on other peoples’ wavelengths, however, you stop feeling you need all of that time alone to think through a problem and it becomes fun working out a solution with someone. Again, this can involve stretches of solo time where you split up then reconvene.

I could go on and on about this and have been meaning to write about it but still haven’t gotten around to it (I have a small draft… not counting all this, lol).

I was lucky enough to start my programming carrier at a team that did full-time pair programming. In a team of 10 to 15 people we switched pairs daily. In retrospect, this was an awesome way to learn a lot of the agile practices, and get to learn from more senior people on the job. It was great, but as mentioned before, could be very exhausting. After having spent seven years in this full-time pairing setup, I had to take a break after what could be called a burnout.
I’ve since learned that for my personality type (introvert, hsp, but seeking deep personal interactions nonetheless), pairing 100% of the time is just too much. I now have defaulted to a more adhoc way of pair programming. I still like to sit together and work on a problem with someone else. There were some great advices mentioned above to make this work. But I also like to work on my own, without someone watching over my shoulder.

One of the things I’ve learned is that some people are not a good fit with this kind of programming. They just can’t adapt or have a balanced way of communicating. Often it’s the “geniuses” that are awfull pairing partners (or team members in general). They have ways of bending their brains in ways I can’t imagine, which makes them solve very difficult tasks. But at the same time they have no incentive to simplify or adapt their solution, so it’s better designed or understandable by their mortal teammates. I’ll choose the better communictor with mediocre skills (but great potential!) over the lone genius cowboy every time.

I won’t ever go back to full-time pair programming. But I will try to do it whenever I feel there is a good opportunity (even if it’s just about education). I often won’t even call it “pair programming”, but I’ll just roll my chair to the other desk, and sit there for a few hours.
But since I’m not a group-thinker, I also need that time alone for deep work.

I have experience with using pair programming effectively. I also have experience with pair programming being inefficient.

In truth, “pair programming” just describes 2 people trying to work together. It depends a lot on the people involved, and the states of those people are not predictable. Pairing with someone on a day when they have meditated, exercised, eaten well and felt at peace is a very different experience to pairing with the same person when they have problems in their life, even if it is just for that day.

Despite having lots (totalling 1000s of hours) of pair programming experience, both at the same desk and remote, I am loathe to form an opinion on “pair programming” other than: It should be used freely but never prescribed.