3 ms·

I wonder how many teams have pair programming engraved into the workflow. As in "for at least a year." I tried it more than once, on different projects with dif

I wonder how many teams have pair programming engraved into the workflow. As in "for at least a year." I tried it more than once, on different projects with different people and it universally sucked. To say that I hate it with passion is an understatement. Perhaps it was because the language was C or because the routine was instigated by a clueless management, but still... in what conditions does it actually work?

trotter_cashion 14y ago
I've found pairing to be very useful when I don't know the stack or codebase all that well. It can certainly be frustrating though when the two people in the pair have extremely mismatched skill levels and are working against a deadline.
- huhtenberg 14y ago
  That's not a pair programming though. It's just one person teaching another whatever there needs to be taught.
  - ryanong 14y ago
    That is pair programming though. The point is to get the other user up to speed so they can contribute more to the project. I like to think of knowledge as a resource with compound interest for the individual and especially for the company. Knowledge is built on what you already know and the more you learn the more ideas and knowledge you can generate. Teaching another is the key principle of pairing. If done correctly somebody should always be learning and teaching.
LOLtampicoLOL 14y ago
The people in the photos appeared alarmingly void of enthusiasm. I'd also love to read any journals that have compiled results on this practice and whether it leads to real gains in productivity or software quality.
matschaffer 14y ago
Pair programming is definitely a different skill and takes practice. Because of this I doubt management could ever force it. You'd need people on the team that know how to do it and can help others learn. And if you have those people, they're probably already implementing it. For me, pairing helps avoid bad decisions before it's too late. There are a lot of choices in programming and when both I and my partner agree on a path it's probably the right one. If we can't agree, usually it's because neither is better than the other. Also not all tasks are right for pairing. Research for example can be frustrating as a pair activity. This is another reason we like this setup since it gets out of the way for non-pair tasks.
jdlshore 14y ago
> In what conditions does it actually work? 1- Programmer buy-in (preferably grass-roots) rather than management dictate 2- Collective ownership of code 3- Frequent switching of pairing partners (switch multiple times per day) 4- Comfortable pairing stations with no "owner" so people can swap partners and desks easily 5- One shared workspace per project with good noise isolation from other projects 6- Office (or two) with a door for private conversations, phone calls, or when you just need to get away from it all 7- Personal space for each person for pictures, storage, checking email, etc. 8- Sensible working hours (pairing is tiring!) 9- Mature participants without major social hang-ups or hygiene issues 10- Mutual respect 11- Thought-provoking work (TDD & evolutionary design tend to make even boring work thought-provoking) 12- Four to eight weeks to get used to it

trotter_cashion 14y ago

I've found pairing to be very useful when I don't know the stack or codebase all that well. It can certainly be frustrating though when the two people in the pair have extremely mismatched skill levels and are working against a deadline.

huhtenberg 14y ago
That's not a pair programming though. It's just one person teaching another whatever there needs to be taught.
- ryanong 14y ago
  That is pair programming though. The point is to get the other user up to speed so they can contribute more to the project. I like to think of knowledge as a resource with compound interest for the individual and especially for the company. Knowledge is built on what you already know and the more you learn the more ideas and knowledge you can generate. Teaching another is the key principle of pairing. If done correctly somebody should always be learning and teaching.

LOLtampicoLOL 14y ago

The people in the photos appeared alarmingly void of enthusiasm. I'd also love to read any journals that have compiled results on this practice and whether it leads to real gains in productivity or software quality.

matschaffer 14y ago

Pair programming is definitely a different skill and takes practice. Because of this I doubt management could ever force it. You'd need people on the team that know how to do it and can help others learn. And if you have those people, they're probably already implementing it. For me, pairing helps avoid bad decisions before it's too late. There are a lot of choices in programming and when both I and my partner agree on a path it's probably the right one. If we can't agree, usually it's because neither is better than the other. Also not all tasks are right for pairing. Research for example can be frustrating as a pair activity. This is another reason we like this setup since it gets out of the way for non-pair tasks.

jdlshore 14y ago

> In what conditions does it actually work? 1- Programmer buy-in (preferably grass-roots) rather than management dictate 2- Collective ownership of code 3- Frequent switching of pairing partners (switch multiple times per day) 4- Comfortable pairing stations with no "owner" so people can swap partners and desks easily 5- One shared workspace per project with good noise isolation from other projects 6- Office (or two) with a door for private conversations, phone calls, or when you just need to get away from it all 7- Personal space for each person for pictures, storage, checking email, etc. 8- Sensible working hours (pairing is tiring!) 9- Mature participants without major social hang-ups or hygiene issues 10- Mutual respect 11- Thought-provoking work (TDD & evolutionary design tend to make even boring work thought-provoking) 12- Four to eight weeks to get used to it