Pair Programming Considered Extremely Beneficial
-
TechCrunch[^]:
You’re in a car driving 100 miles per hour on a dirt road. The turns are 100-degree hairpins and there are inclines and dips that would make a normal car’s shocks fall right off their axles. Lucky for you, you’re not alone. You have a partner. Because there are two of you, you can split the responsibilities of getting to the finish line first – in one piece. This is the basis of pair programming. The deliberate practice of staffing every workstation with two software engineers focused on writing software together.
There’s also pair programming’s little-talked-about stepbrother: Blame the guy in the next cubicle.
-
TechCrunch[^]:
You’re in a car driving 100 miles per hour on a dirt road. The turns are 100-degree hairpins and there are inclines and dips that would make a normal car’s shocks fall right off their axles. Lucky for you, you’re not alone. You have a partner. Because there are two of you, you can split the responsibilities of getting to the finish line first – in one piece. This is the basis of pair programming. The deliberate practice of staffing every workstation with two software engineers focused on writing software together.
There’s also pair programming’s little-talked-about stepbrother: Blame the guy in the next cubicle.
Tried this once many years ago. Never again. We ended up nearly killing each other: both had very different ideas and ways of working - just didn't work. The only way I can ever see this working is if one is submissive, one dominant in which case you might as well not bother. One of the worst ideas ever. :thumbsdown:
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
TechCrunch[^]:
You’re in a car driving 100 miles per hour on a dirt road. The turns are 100-degree hairpins and there are inclines and dips that would make a normal car’s shocks fall right off their axles. Lucky for you, you’re not alone. You have a partner. Because there are two of you, you can split the responsibilities of getting to the finish line first – in one piece. This is the basis of pair programming. The deliberate practice of staffing every workstation with two software engineers focused on writing software together.
There’s also pair programming’s little-talked-about stepbrother: Blame the guy in the next cubicle.
I think the real little brother to pair programming is called peer reviews. While in car racing it is important to get the job done in record time, in programming we have a more relaxed schedule. So why not let one person start the job and bring the other in when the first one thinks he/she has everything in place. For some really critical parts of code that are extremely hard to test, we have experimented with pair programming -- without even having a name for it. And the results were not bad at all. It's just a little expensive for every-day code.
-
TechCrunch[^]:
You’re in a car driving 100 miles per hour on a dirt road. The turns are 100-degree hairpins and there are inclines and dips that would make a normal car’s shocks fall right off their axles. Lucky for you, you’re not alone. You have a partner. Because there are two of you, you can split the responsibilities of getting to the finish line first – in one piece. This is the basis of pair programming. The deliberate practice of staffing every workstation with two software engineers focused on writing software together.
There’s also pair programming’s little-talked-about stepbrother: Blame the guy in the next cubicle.
Two programmers. One workstation. One cubicle. You would be lucky to get 50% out of each programmer; that is, assuming they were putting out 100% in the first place.
-
I think the real little brother to pair programming is called peer reviews. While in car racing it is important to get the job done in record time, in programming we have a more relaxed schedule. So why not let one person start the job and bring the other in when the first one thinks he/she has everything in place. For some really critical parts of code that are extremely hard to test, we have experimented with pair programming -- without even having a name for it. And the results were not bad at all. It's just a little expensive for every-day code.
Peer reviews? In the 1970s, it was called Egoless Programming. We invent new terms but not new technology that would really increase programmer productivity.