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

51–60 of 180 posts

Re: Against Pair Programming

#51

Post by alisonkisk »

jasode wrote: post #16

When I read a New Yorker article about Google, I was surprised to learn that Jeff Dean and Sanjay Ghemawat do a lot of pair-programming. Excerpt from: https://www.newyorker.com/magazine/2018/12/10/the-friendship... >“I don’t know why more people don’t do it,” Sanjay said, of programming with a partner. >“You need to find someone that you’re gonna pair-program with who’s compatible with your way of thinking, so that t…

They aren't "just" pair reprogramming -- they are practically married. They pair only with each other, forever, and they are best friends. It's not an arbitrary or rotating matchup.

Re: Against Pair Programming

#52

Post by ravishi »

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…

His argument seems focused on a single output: developer velocity. That's a dangerous metric to optimize for.

Re: Against Pair Programming

#53

Post by candyking »

I don't agree at all. The author only considers short term productivity and does not acknowledge the long term benefits of the skill sharing.

Let's make up a metric, du (dev units), for how much a developer produces in a day, and let's say an average developer produces 100du per day.

If we have two developers, Sally and Frank, producing 120du and 70du respectively. Short term, for these two people to pair program, the production of the pair programming has to be greater than or equal to 190du.

But if we instead consider how productivity increase as experience grow, perhaps the next day, Frank will produce 80du and Sally 121du, then this is definitely worth it long term.

I would agree with the author if the question was "ONLY pair programming" vs "ONLY individual programming", but that is a stupid question.

Re: Against Pair Programming

#54

Post by avereveard »

> Let's start with the economics. 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.

this is immediately wrong. since you're using only one computer and desk, the output can break even at less than 2x/pair, since you're not paying maintenance for double the space.

the rest is absolutely missing any data backing it up, so it's completely pointless to argue about.

Re: Against Pair Programming

#55

Post by rr808 »

I hate someone watching what I'm doing as often I'm trying things out and experimenting. However I've learned loads from watching others - usually its unrelated stuff like interesting tests, command line shortcuts, language features etc.

Re: Against Pair Programming

#56

Post by yessirwhatever »

The lack of understanding that this article shows about the author is just amazing. The dude looks to have extensive history in engineering and I don’t doubt that his experience can help in making him decide on what could work for him. But almost every one of his statements are not how one should think of pair programming, or is the purpose of it to generate > 2x value at all. Considering the potential technical debt that almost always amounts to a long debt repayment period (that is if even that’s possible) or that what works for one programmer may not work for others!

Re: Against Pair Programming

#57

Post by mnsc »

denton-scratch wrote: post #40
Tabular-Iceberg wrote: post #7

Earlier quoted context omitted.

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 payi…

How dare you call me out like that!

But really, when you have trust rather than competition between colleagues it's absolutely ok to plan regular breaks and pull the emergency break when your focus juice has run out for the day. So depending on culture and how stable/jelled-in your team is pair programming shouldn't a exhaustive grind. That doesn't seem sustainable.

Re: Against Pair Programming

#58

Post by gherkinnn »

Veuxdo wrote: post #34

Do other professionals do pair _______? Pair writing? Pair hairdressing? Like standups and pointing, it feels like a patronizing exercise we only force on devs.

Absolutely.

Penn and Teller develop their tricks together. Two-seater attack aircraft are a thing. Rally drivers have a driver and a navigator. Apprentices are taught in part through pairing.

> Like standups and pointing, it feels like a patronizing exercise we only force on devs.

There's truth in that. On one hand, many of our practices is formalised problem solving under the (non-)constraints of software. Others are cargo culted, clueless, patronising and painful.

Re: Against Pair Programming

#60

Post by tkindy »

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 generally agree with your take.

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

I think PR reviews can be a resource for other engineers on the team to learn from beyond just the PR author. Granted, I think pair programming can probably deliver these lessons more effectively since you can have a live conversation about it and clear up any confusion there.

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

> And this is better, because...?

I don’t know the author’s feelings here, but I think this makes some sense in the context of the rising popularity of remote work. It isn’t necessarily a given that you’re in a similar time zone to your teammates.

I’ve also been interested in the topic of async work throughout the pandemic, with companies like Gitlab and Doist as examples who also evangelize the practice. I’ve pushed for some of those async practices on my team at work but feel like we’ve had mixed to little success with them.

So I agree with your skepticism of “async is better”, even if there was some reasoning provided.

Post reply on HN