I've used pairs off and on at work but never long-term. The part I find most useful about coding side-by-side with someone is that there is someone to question (or reassure) every small decision I make (for better or worse!). Particularly in coding, there are always many ways to solve each problem and having two sets of eyes (with even mediocre brains attached) frequently yields a better solution.
I find that a necessary part of pair programming is to switch up the pairs fairly often. Pairs have a tendency to become "comfortable" with each other's habits and can fall into a rut -- pairs should be shaken up to keep each everyone on their toes.
Also, you can learn a lot (about programming, people, life, etc.) when pair programming.
I'm not big on the pair thing; not saying it doesn't work for a lot of people but I just don't care for it in my projects. I like it for doing code reviews or going through to tighten things up, but not as an all-the-time development strategy.
If you want a better guarantee of having 3 pairs, go with 7 developers. Then you're covered when one is sick/on vacation/on jury duty/off getting married/stuck at the DMV, etc., and you've built in some insurance in the event that one of your coders gets run over by a bus.
Comments
6 developers makes 3 pairs.
I've used pairs off and on at work but never long-term. The part I find most useful about coding side-by-side with someone is that there is someone to question (or reassure) every small decision I make (for better or worse!). Particularly in coding, there are always many ways to solve each problem and having two sets of eyes (with even mediocre brains attached) frequently yields a better solution.
I find that a necessary part of pair programming is to switch up the pairs fairly often. Pairs have a tendency to become "comfortable" with each other's habits and can fall into a rut -- pairs should be shaken up to keep each everyone on their toes.
Also, you can learn a lot (about programming, people, life, etc.) when pair programming.
I'm not big on the pair thing; not saying it doesn't work for a lot of people but I just don't care for it in my projects. I like it for doing code reviews or going through to tighten things up, but not as an all-the-time development strategy.
If you want a better guarantee of having 3 pairs, go with 7 developers. Then you're covered when one is sick/on vacation/on jury duty/off getting married/stuck at the DMV, etc., and you've built in some insurance in the event that one of your coders gets run over by a bus.