I can't imagine pairing full time, but I did it for brief stints as a customer of Menlo Innovations. All customer code must be written by pairs, but one option

I can't imagine pairing full time, but I did it for brief stints as a customer of Menlo Innovations. All customer code must be written by pairs, but one option to reduce costs is to have the customer supply half of the pair team, so I did this for a few half days one one project. This is obviously scary at first because someone is going to watch me code! It turns out that it is perfectly normal to use google/stackoverflow to write programs, and I actually found the experience reassuring once I got past the shock of having someone look over my shoulder. My team does not do pair programming, but I understand why Menlo does it, it it works great for them. Some benefits I saw were: 1) It is great for junior developers. It's like turning mentoring up to 11. This means that it is much easier to hire people because you can fill seats and actually train people. 2) They have a special kind of family friendly culture where people have their infants in the office. One half of a pair can be holding their 3 month old and still contribute as half of the pair. I think they get slightly less keyboard time, but it still works. 3) Developers changed projects a lot. Splitting the day between two projects seemed normal, and 3-4 different projects in a week was standard. The pairs provide some continuity during these transitions. Major down sides include the fact that you can't visit HN during work time. That means that the opinions here are likely to be skewed. There are places and situations where pair programming isn't a good fit, but after seeing it in practice, I think there are also places where it is a good fit.