3 ms·

> This is also basically the standard critique of pair programming, but I've never heard it come from somebody who has done much pair programming. I've done a

> This is also basically the standard critique of pair programming, but I've never heard it come from somebody who has done much pair programming. I've done a fair amount of pair programming and generally found it to be an inefficient waste of time. Having colleagues around to bounce an idea off of is great, but there's almost never the need to have two people continuously coding together.

wpietri 11y ago
Ok. Now I've heard it from one person. But I think "there's almost never the need to have two people continuously coding together" is a pretty strong conclusion from one person's experience. Do you mean that you haven't noticed the value in it? One possibility is that your team was maybe not so good at it. Sometimes that happens: http://agilefocus.com/2009/01/06/21-ways-to-hate-pair-programming/ http://agilefocus.com/2009/01/06/21-ways-to-hate-pair-progra... Another is that you were working in a domain where the benefits of pairing don't matter so much. For me, they include improved code quality, less siloing, making it easier to bring people on to the team, faster iteration, and a greatly increased ability to actually take vacations due to improved truck factor. On long-lived code bases with high business value and fast iteration, quality and collaborative ease become very important to me. Basically, I put pairing in the same category as code reviews, but I think it's much more efficient. And others do as well: http://slesinsky.org/brian/code/pair_versus_review.html http://slesinsky.org/brian/code/pair_versus_review.html
herval 11y ago
Count me in too. Worked almost two years of exclusive pairing. Other than onboarding new people to a codebase or ramping up juniors, it's the least efficient way to work I ever experienced. I don't have any formal metrics on code quality to compare there, but from what I can tell, the results were nothing close to "the best codebase ever".

wpietri 11y ago

Ok. Now I've heard it from one person. But I think "there's almost never the need to have two people continuously coding together" is a pretty strong conclusion from one person's experience. Do you mean that you haven't noticed the value in it? One possibility is that your team was maybe not so good at it. Sometimes that happens: http://agilefocus.com/2009/01/06/21-ways-to-hate-pair-programming/ http://agilefocus.com/2009/01/06/21-ways-to-hate-pair-progra... Another is that you were working in a domain where the benefits of pairing don't matter so much. For me, they include improved code quality, less siloing, making it easier to bring people on to the team, faster iteration, and a greatly increased ability to actually take vacations due to improved truck factor. On long-lived code bases with high business value and fast iteration, quality and collaborative ease become very important to me. Basically, I put pairing in the same category as code reviews, but I think it's much more efficient. And others do as well: http://slesinsky.org/brian/code/pair_versus_review.html http://slesinsky.org/brian/code/pair_versus_review.html

herval 11y ago

Count me in too. Worked almost two years of exclusive pairing. Other than onboarding new people to a codebase or ramping up juniors, it's the least efficient way to work I ever experienced. I don't have any formal metrics on code quality to compare there, but from what I can tell, the results were nothing close to "the best codebase ever".