> Pairs tend to devolve to least-common-denominator performance. Experts paired with novices need to move as slow as a novice. I think this misses a lot of the

> Pairs tend to devolve to least-common-denominator performance. Experts paired with novices need to move as slow as a novice. I think this misses a lot of the benefit of pair programming. The person with more experience on the project can point the other person directly to the places where it's natural to implement functionality, instead of the newbie having to scan through potentially the entire project structure so they can orient themselves. An expert can give a novice a heads-up about things they will be asked to change in code review, so they don't make the mistake in a dozen places and have to fix it a dozen times. Often pair programming happens because there's a mix of expertise -- there's a change that requires both familiarity with the project and a certain kind of technology expertise, so a junior programmer who knows the project pairs with an expert from another team, and the change gets done faster than either one could do it alone. Pair programming is also a great way to use excess capacity in a dev team. Martin Thompson points out in one of his talks that a system running at full capacity is slow and fragile, so you want your dev teams to work below capacity most of the time. Pair programming is a great way to improve quality and share knowledge, and when you have excess capacity, it's free!