> The success of pairing depends heavily on the skill and personalities of those involved. If the skill disparity is too great, you end up with one person doing

> The success of pairing depends heavily on the skill and personalities of those involved. If the skill disparity is too great, you end up with one person doing all the thinking while also lecturing the newbie. If neither collaborator likes the other, you'll have issues. Even something like preferring different editors can get in the way. Very much agree. I was a client at Pivotal for a few months, and learned a ton from them while pairing. We brought their XP style (slightly tweaked) back to our office once our contract with them was up, and continued pairing about half of the time. We could all get along well enough, and had agreed on using the same editor, so the only pain point I felt was when working with people with a different skillset. Though the different skillset problem made development go slower, but the more experienced people are teaching the less experienced people, hopefully making the tradeoff worth it. Another advantage to pairing is that it keeps developers honest -- if you're supposed to be doing TDD, then ideally your pair helps you stick to it instead of taking shortcuts you "know" are okay. Edit: oops, grandparent asked for negative experiences. The only ones I had were frustration when working with people who were already frustrating to work with. (Ideally, while pairintg they'd be learning, and would become less frustrating to work with...) I do agree with parent's point about it being less useful when banging out boilerplate or obvious solutions, but that's not really a horrible experience, just a little wasteful feeling.