Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Against Pair Programming

matt-rickard.com

Post reply on HN
Print view View original

31–40 of 180 posts

Re: Against Pair Programming

#31

Post by fsloth »

pydry wrote: post #18

>The output of pair programming must be greater than 2x the output of a single programmer to make sense. IME it does. Most of coding is identifying problems and two sets of eyes lets you hone in on the problems quicker. With design, two sets of eyes spots things that you will otherwise miss. Programming isnt chopping wood. If you're experience with it is that you're bashing out code like you're on a factory productio…

>> there are more time and cost efficient ways to share knowledge between team members > I've never seen this happen once.

Me neither.

When you need pairing, it's super powerful and cannot be replaced. When you don't need it, don't do it.

Re: Against Pair Programming

#32

Post by Zigurd »

This sentence can be (and has been in the comments) criticized from many angles:

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.

I think it's bad because it shows a lack of understanding of metrics: The only valid productivity metric is code that works, and that everyone agrees does what it is meant to do. Code that does what it is meant to do without bugs is worth a lot more. Try quantifying that. I dare you.

Counterbalancing that is time-to-market. Expedient hacks are worth a lot, too. That you can, sort of, quantify. Risk capital costs a lot more than cash flow. Do your coders understand that?

Where to use pair programming? Probably not when you are racing to find product market fit. Possibly yes when you can lose existing customers due to a nasty bug (that may have root causes in early stage expedience).

Avoid dogma.

Re: Against Pair Programming

#33

Post by xenocratus »

kstenerud wrote: post #4
davedx wrote: post #2

Reducing 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 assume you mean this part:

> While pair programming might achieve some goals as a pedagogical tool, there are more time and cost efficient ways to share knowledge between team members.

It's a very hand-wavey dismissal - "yeah, that doesn't work... NEXT!". I've enjoyed both sides of the learning process in pair programming and implying that documentation can cover everything that can be learned like that is, in my experience at least, laughable. It's not just about code, it's about the whole process, including other tools you might use, where and how to find things, etc. Engineers have different backgrounds that might've taught them different ways of approaching certain tasks. Some of those might stick

Re: Against Pair Programming

#35

Post by stevage »

Ha. I dislike pair programming as much as anyone, but this argument is really weak. It doesn't sound like he has actually had much experience of it, and is just judging it from the outside.

But let's go through some points:

>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.

In "output" you have to include quality (fewer bugs), improved codebase knowledge (bus factors etc), improved team cohesion etc.

> Pair programmers tend to give feedback that's more appropriate in a design or code review.

What's his evidence? Why is it more appropriate there (after the code is written) than here (before/during)?

> For the pairs that follow this, the only feedback that's left tends to be bikeshedding or stylistic, both of which kill velocity.

That's, um, bullshit. Pair programming can pick up mistakes before they propagate, which increases velocity.

> It's like having a backseat driver.

I'd say it's more like having a second pair of eyes while you're doing a tricky reversing maneuver.

> Alternatives like code reviews, design reviews, and general documentation are much better 1-to-n ways to share knowledge instead of 1-to-1.

Aren't code reviews and design reviews 1-to-1 as well? Or worse, n-to-1.

> In addition, most of these alternatives be done asynchronously.

And this is better, because...?

Re: Against Pair Programming

#36

Post by stevage »

brianmcc wrote: post #13

I'm pair programming ambivalent. A lot folks like it. I mostly don't, but I enjoy collaborating more broadly, and sometimes a pairing session can be truly invaluable when the task at hand is right. I think it has many benefits in that at least knowledge isn't entirely siloed with 1 contributor. It's not the silver bullet to solving wider system awareness problems though. >> Not to mention the coveted flow state that…

Yeah, personally I don't particularly like it, because I don't particularly like talking about the coding I'm doing - I like just being in it. But I can totally see that it's very effective and enjoyable for a lot of people.

Re: Against Pair Programming

#38

Post by lmilcin »

Pair programming is exhausting and definitely not for everybody and for every single day.

But.

This is still the best way to exchange knowledge and produce code when normally you would need a code review.

Pair programming is not a waste of time. It does not cost twice as much -- it actually costs less.

It costs less because having another person working with you cuts all the procrastination and keeps things in focus.

It costs less because now you have to discuss every part of the design with another person which is likely going to lead to better design.

It costs less because if one person doesn't know it or spot it, the other person will.

It costs less because you get immediate knowledge transfer and two people who can continue the project. Things can continue moving forward even if one person gets sick or leave the project.

It costs less because people learn new stuff crazy fast when they can observe other person doing things they don't know.

It costs less because actual people (like me) like to work with other people. It is fun.

It costs less because code review is a shitty process where 99% of people fake they made a review and only pick on stuff that immediately stands out rather than actually trying to thoroughly understand and analyse the change.

Unless you have a brilliant developer that can do everything by his/her own with no help or review. Consider yourself lucky.

Re: Against Pair Programming

#39

Post by toqy »

stevage wrote: post #35

Ha. I dislike pair programming as much as anyone, but this argument is really weak. It doesn't sound like he has actually had much experience of it, and is just judging it from the outside. But let's go through some points: >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. In…

> I'd say it's more like having a second pair of eyes while you're doing a tricky reversing maneuver.

I’ve always liked the rally racing driver/navigator analogy for explaining pair programming. It tends to go better if you generally follow those roles when doing it too.

Re: Against Pair Programming

#40

Post by denton-scratch »

Tabular-Iceberg wrote: post #7
dustingetz wrote: post #3

read 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.

> pair programming sessions often get sidetracked

I've never experienced that. My experience was that pairing sessions were continuous, bloody hard work. My partner and I would have our noses to the grindstone throughout the session, which was strictly time-delimited (10AM to 5PM). I'd go home exhausted. Whether you're driving or navigating, you have to concentrate. The navigator has to show the driver that he's paying attention; the driver has to account for what he's doing.

Working solo, it's much easier to get sidetracked. Feeling overloaded? Well, spend a few minutes on HN.

Post reply on HN