Against Pair Programming
matt-rickard.com
Against Pair Programming
1–10 of 180 posts
Re: Against Pair Programming
#2Reducing pair programming to numerical economic value like that is quite absurd: "Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense."
The point of pair programming is to teach and learn from each other, not to maintain some pointless productivity metric.
Utterly ridiculous. I despair sometimes.
Re: Against Pair Programming
#3read any hn thread about how much time software engineers spend working. big company programmers are putting in 6 hours of effort per week.
Re: Against Pair Programming
#4Reducing pair programming to numerical economic value like that is quite absurd: "Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense." The point of pair programming is to teach and learn from each other, not to maintain some pointless productivity metric. Utterly ridiculous. I d…
Please read the article all the way through before commenting. Your other points are already addressed.
Re: Against Pair Programming
#5I've found pair programming has helped in the past when working on really complex or convoluted code.
I could sit for a day myself and maybe get my head around it, or pair program with someone else and between the two of us we get it knocked out in a few hours.
If you only have a simple code base, I think pair programming doesn't have a lot of value. But when you are in a 5million + LOC legacy app, pair programming can help a lot IME.
Re: Against Pair Programming
#6"I did it wrong so it must be bad," the blog post.
Re: Against Pair Programming
#7read any hn thread about how much time software engineers spend working. big company programmers are putting in 6 hours of effort per week.
Maybe that’s the point. It’s harder to just sit at your desk and space out when you’re right next to someone else.
On the other hand I feel like pair programming sessions often get sidetracked into interesting conversations about technology or just about anything else that’s interesting, so that part is nice.
Re: Against Pair Programming
#8Reducing pair programming to numerical economic value like that is quite absurd: "Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense." The point of pair programming is to teach and learn from each other, not to maintain some pointless productivity metric. Utterly ridiculous. I d…
Please read the article all the way through before commenting. Your other points are already addressed.
I think davedx read the article, davedx even copy/pasted/quoted it, and I totally agree, the author is being overly simplistic in the analysis made.
And on the other hand, somehow the author of the article passes asynchronous code reviews as good thing. I mean, that is THE problem that pair/mob programming is solving, imho.
Re: Against Pair Programming
#9Reducing pair programming to numerical economic value like that is quite absurd: "Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense." The point of pair programming is to teach and learn from each other, not to maintain some pointless productivity metric. Utterly ridiculous. I d…
[deleted]
Re: Against Pair Programming
#10Reducing pair programming to numerical economic value like that is quite absurd: "Since we are employing two programmers to do work on the same keyboard at the same time, the output of pair programming must be greater than 2x the output of a single programmer to make sense." The point of pair programming is to teach and learn from each other, not to maintain some pointless productivity metric. Utterly ridiculous. I d…
Please read the article all the way through before commenting. Your other points are already addressed.
Except that the points aren't really addressed.
The article argues in favor of "code reviews, design reviews, and general documentation" but it totally avoids discussing the merits and disadvantages of them.
It's not only pair programming that has pro and cons, and so using a different process (or more likely, a mix of different processes) always implies a tradeoff.