As time goes by a skill gap grows between the developers and one will become the go to person while the other just watches. Especially if one part of the pair d

As time goes by a skill gap grows between the developers and one will become the go to person while the other just watches. Especially if one part of the pair develops outside of work and the other does not. This creates resentment and results in the more skilled developer having to use less elegant solutions to a problem so that the other developer can understand what is happening. Additionally, I feel long term pairing creates tunnel vision and stifles innovation as there is no time to stop pairing and think out a solution. The focus is cranking out features without spending the time that you get working alone to get more creative. The lack of creativity is actually a side effect of the increased productivity. You are definitely more productive working as a pair because there are no breaks. You can't check hackernews, reddit, etc when you have some watching everything you do. I view this as a good thing, but I wouldn't be checking those sites during work time anyway. Sometimes I just need a few minutes to research alternative solutions instead of just going for the first one that the pair comes across. In my view, pairing works best when used in moderation. Adding a new team member? Have them rotate and pair with different team members for the first 4 months. Pairing will get them up to speed with the rest of the team in no time. The new hire will learn the programming culture of the company and experience various team members insights. I think pairing together to work on a feature on an occasional basis is also a great team building strategy. The key is moderation and rotating the pairs so that it doesn't become stale. Having experienced the Pivotal way for a good amount of time, I feel they have taken pairing too far.