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

11–20 of 180 posts

Re: Against Pair Programming

#11

Post by jordanbeiber »

Resource optimization vs. Flow.

It all comes down to measuring outcomes over time. Doing agile is doing right-ish things at the right-ish times, including ways of working.

Use retros - are we being efficient over time? Why and when? Why not and when not?

My teams tend to flow in and out of pairs, mobs and single contributions, all depending on task at hand and circumstance.

Flow! Are you flowing? How do you know?

Over time I’ve noticed that really well gelled pair and/or mobs deliver more consistently, over longer periods of time. YMMV.

Re: Against Pair Programming

#12

Post by adrianomartins »

spacemanmatt wrote: post #6

"I did it wrong so it must be bad," the blog post.

Most definitely. Once thing that I feel is not said about pair/mob programming, and also for Trunk Based Development for that matter, is that they essentially require a different mindset and ways to approach/solve a problem.

If you're going to develop a feature in pair-programming in the exact same way you would if you'd be doing it alone, yes, it might not be the most effective thing.

If both/many programmers discuss the ideia first, implement it, correct it on the fly, and when it's done it's completely done, with no waiting time, no delaying the value, no miscommunication in comment boxes, then it's highly effective.

Re: Against Pair Programming

#13

Post by brianmcc »

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 most developers look for.

That is perhaps the single biggest factor around why I prefer not to pair for the most part. Frankly I just can't think as well about creative, problem solving stuff when I'm pairing.

There's also an "enjoyability" issue.

If people enjoy pair programming, and this will vary by individual, they'll find ways to keep practicing it even if it's not the most efficient option (and actually there's a good case it is long term cost effective).

If people do not enjoy pair programming, they'll find ways to avoid practicing it even if has many economic or systemic benefits.

As we often find, it's a people thing: we remain emotion-driven and reward-driven beings and that isn't going to change any time soon.

Re: Against Pair Programming

#14

Post by vector_spaces »

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…

Agreed, what a disappointing argument.

Personally I love pairing -- I've learned a lot from pairing with others over the course of my career. Earlier in my career, seeing how others worked went a long way towards improving my own workflows.

I think there are some valid criticisms to be made against mandated pair programming. In some circumstances, such as thinking through a solution on the fly to a subtle bug or challenging data problem, I will usually need some alone time with the problem to come up with anything worthwhile. I'm introverted, so having someone on a screen sharing session or sitting next to me (sometimes) carries a burden that will probably reduce my creative output. But that's not always the case! Sometimes it's great having someone to point out lapses in reasoning or suggest approaches I wouldn't have thought of, or to be that person for someone else.

Anyway, I only thought to mention that because the angles given in TFA were so disappointing and also because I have seen some job ads that mention something to the effect that all programming that happens in that shop is pair-programming, and while I love pair-programming, that sounds like a special kind of hell I would love very much to avoid.

But then, I've never worked in such a shop -- maybe it's great, even if it's probably not for me?

Re: Against Pair Programming

#15

Post by mjw_byrne »

Pair programming easily achieves the >2x speed boost though. The driver focuses on the technical details of writing high-quality code, implementation, proper variable naming and so on whilst the navigator keeps track of the overall task, provides extra short-term memory, spots silly mistakes/typos, focuses on business logic etc. So instead of one programmer juggling too much and stalling, getting bored/frustrated, losing confidence, taking shortcuts to try to keep up and making a mess, you have two programmers in a state of flow producing high-quality work.

As a side-effect, you also get great shared knowledge of the code base.

Re: Against Pair Programming

#16

Post by jasode »

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 the two of you together are a complementary force,” Jeff said. [...]

Re: Against Pair Programming

#17

Post by tweakimp »

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

Not at all. Two programmers working on the same project at the same time is already slower than one programmer working twice as long because these two have to communicate. And during pair programming, the communication is sped up.

In my experience, pair programming is really fun and helpful for some parts of my work, for example brainstorming solution ideas or finding bugs.

Re: Against Pair Programming

#18

Post by pydry »

>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 production line then something has gone wrong.

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

I've never seen this happen once. If somebody managed to write docs that correctly anticipated every potential question I'd be very surprised.

Re: Against Pair Programming

#19

Post by usrbinbash »

IMHO, pair programming is a useful thing, but not for the reasons it's usually sold on.

It is a really good oboarding vehicle. Pair an Experienced Dev and a new hire, and let the former guide the latter through the codebase. It also works great for implementing changes involving very complex parts of the codebase, usually the kind that interact with many different subsystems, which can get really tricky toget a good grasp on.

Re: Against Pair Programming

#20

Post by JackMorgan »

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.

This is the biggest thing I have seen with pairing when it works. People are less likely to disrupt a pair, but they'll happily bother a single person. Enough of those happen a week, and the pair gets 20+ hours of coding vs the two singles only getting six each.
Post reply on HN