I had a very positive experience with pair programming on a project for about ten months. We (myself and one other guy) definitely did serious work. We built an

I had a very positive experience with pair programming on a project for about ten months. We (myself and one other guy) definitely did serious work. We built and delivered a complex piece of well tested software that is now running on aeroplanes (non safety-critical software). It was also a distributed system, adding to the complexity, where some parts run on AWS and some on the planes, communicating over satellite internet (which may or may not be available). We did it because we decided it would be the most effective way to work. There were only two of us on the project, so it was very important that both of us understood all aspects of the design and code. It was important to us that we spot issues early and that our test cases were comprehensive (we also used generative property-based testing to find actual bugs, which included simulating network errors, crashes etc). We designed on a whiteboard, then we would pair to implement it. We worked remotely about 50% of the time (using ScreenHero to do remote pair programming. I miss ScreenHero). Yes, the goal was to share thought processes, but it was also to produce high quality code, spot errors, come up with edge cases and tests. And to document everything. Personally, it was one of the most successful projects I ever worked on. The pair programming was exhausting, but very effective.