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

151–160 of 180 posts

Re: Against Pair Programming

#151

Post by sascha_sl »

bluefirebrand wrote: post #134
sascha_sl wrote: post #73

Earlier quoted context omitted.

Asynchronous workflows should be the default. Interruptions are almost universally bad, so being able to fit a code review into your work day whenever you want is much better. Even if you have a fixed meeting, you might've just started to get productive on something else, or maybe there's something that actually needs to be handled synchronously, like an incident. It also is a lot more pleasant for neurodiverse devel…

I also have ADHD and find pair programming is great for me. Having a person that I am working directly with helps me keep on task and prevents my brain wandering off to do other things or scattering around a bunch of tasks. Sometimes it helps me to have an external force help direct my focus.

I've completely blanked out more than once on pair programming where my attention went into what I like to call "brute force mode", where your working memory scatters every few seconds or so, and you keep starting thoughts from scratch.

It honestly feels like torture to me.

Switching tasks lets me reset from this state well enough, so I consider it essential coping.

Re: Against Pair Programming

#152

Post by sascha_sl »

SideburnsOfDoom wrote: post #143
sascha_sl wrote: post #73

Earlier quoted context omitted.

Asynchronous workflows should be the default. Interruptions are almost universally bad, so being able to fit a code review into your work day whenever you want is much better. Even if you have a fixed meeting, you might've just started to get productive on something else, or maybe there's something that actually needs to be handled synchronously, like an incident. It also is a lot more pleasant for neurodiverse devel…

> Asynchronous workflows should be the default. Interruptions are almost universally bad, What's great, though, about getting some work ready, creating the PR; and then waiting .. Minutes? Hours? ... days? who can tell? For a response. if you're wanting "productive", that isn't it.

But you're breaking someone else's productive time. The way around this is (1) having enough work prepared that you can start on something else and (2) cutting your PRs well enough for them to be entire (sub-)tasks. And if you can't, maybe you need to cut smaller tasks.

Re: Against Pair Programming

#153

Post by cudgy »

lkois wrote: post #30

I recently took a junior role working on a decades old legacy codebase, in which all developers and almost everyone who had touched the code had quit in the previous year. The week I joined, the most experienced remaining developer put in his 2 weeks notice, after a 9 month tenure. The next most experienced had only been there a month or two. We then spent every day of the next 2 weeks on near 8 hour videocalls devel…

They figured it out on their own in a month or two. You figured it out with 2 other developers in a few weeks. Meanwhile, those developers did not make progress on their tasks. This seems to only be an advantage for you as the newcomer to get ramped up quicker.

Another potential disadvantage is that you may have been influenced by their methods and not having looked at the code independently, your own insight and input may have be limited.

Re: Against Pair Programming

#154

Post by gopher_space »

JKCalhoun wrote: post #88
mrozbarry wrote: post #84

Earlier quoted context omitted.

Just to tag along (I was going to quote and write just about all the same things), but with two developers, the HUGE value-add is codebase knowledge. If two people on a team regularly contribute to a repo, one person likes to work on feature A, and the other feature B, and all of a sudden, the feature B person leaves and never comes back, that will kill velocity. Even if feature A person has been doing code reviews,…

I'll tag along as well. (But I happen to think pair programming is a beautiful thing.) Code reviews in real time, in situ. "White board discussions" in real time, in situ. Learning how someone else codes/debugs. These are all worth the price of pairing up engineers in my mind. If we're talking agile development, I would love it if all engineers could get paired up for at least one sprint a year. Especially less exper…

My biggest gripe with pair programming is that people are already too close to me when they're at their own desk minding their own business. I love working on closely related or even intertwined projects, however. It'd be interesting to work on a really good pair team for a little bit, see what a "perfect example" looks like.

Re: Against Pair Programming

#156

Post by eyelidlessness »

I don’t enjoy pair programming, primarily because it’s a lot of added cognitive load, and I’m already sensitive to that working solo. But one huge benefit of pairing which I think deserves more emphasis is that it gives each dev insight into how the other thinks about: the problem, the domain, design details which evolve during the process, risks/pitfalls, pretty much all of the stuff that can be more contentious or surprising in review. That said, a lot of that can also be had in interactive review, which I think people should do more often.

Re: Against Pair Programming

#157

Post by usefulcat »

rr808 wrote: post #41
lkois wrote: post #30

I recently took a junior role working on a decades old legacy codebase, in which all developers and almost everyone who had touched the code had quit in the previous year. The week I joined, the most experienced remaining developer put in his 2 weeks notice, after a 9 month tenure. The next most experienced had only been there a month or two. We then spent every day of the next 2 weeks on near 8 hour videocalls devel…

Nice. How do you sustain this for 8 hours a day though? After 45 minutes my brain starts to sag.

At one time in my career I pair programmed pretty much all day, every day for the better part of four years, with the same person. We started with an existing codebase, but even from the start most of the work we did was on new features.

It is intense, but--at least in my experience--it was also very productive. You basically can't/don't ever slack off. And I learned a lot from the other developer (mainly about various tools). Things that theoretically I could have learned on my own but in practice I probably never would have.

If I had it to do over again I would definitely choose to do it again.

Re: Against Pair Programming

#158

Post by brabel »

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…

> The point of pair programming is to teach and learn from each other, not to maintain some pointless productivity metric.

I don't understand your point. In a world where most developers are almost certainly gone in a couple of years, programmer velocity seems to me to be more important than getting people to understand lots of parts of the code base (once they understand 2 or 3 big chunks of it they'll be probably gone)... and to get to understand a small part of the whole it only takes a few sessions of either pair programming or, better, design sessions.

I may sound like someone who's given up on "sharing knowledge" and just cares about output... and you'd be right. Because that's the world I live in, not the world I would like to live in...

I've been in the same company for 6 years now. Got a 25% raise recently because they don't want me to leave (they were damn right I would leave soon otherwise)... in this time, I've seen many come and go... spending time teaching them more than they need to accomplish the work they need to do in the next few months is what I would call a total waste of my time... I show them what they need to see, then leave them to their own devices. Most of them are smart enough to get stuff done after just a couple of design clarifications... If I had to sit all day with them trying to explain how everything works everytime we made a change our output would go down 90% and we would be out of business in a few years.

Re: Against Pair Programming

#159

Post by nijave »

>Experts paired with novices need to move as slow as a novice

I actually find this to be highly effective for times experts aren't working at expert speeds. Sometimes you just get off a big project or have been heads down a couple days and it's nice to relax and talk things through with someone else writing code instead of trying to churn it out yourself.

Likewise, novice and expert can be context dependent. Novice doesn't necessarily mean they can't write code but they might not be very familiar with the domain.

The alternatives are read/write docs or have a meeting? The former is asynchronous so there will envitably be back and forth before the docs have useful info. The latter is similar to pairing except no code is being written and information is just being queued for use later

Re: Against Pair Programming

#160

Post by nijave »

kstenerud wrote: post #148
adrianomartins wrote: post #8

Earlier quoted context omitted.

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.

I don't understand... what is wrong with asynchronous code reviews? From my POV code reviews are the solution to the pair programming problem.

Async code reviews are slow. A code review is about getting people to agree on the code being reviewed (ideally using a set of objective guidelines). Instead of having a review done in an hour, for instance, it can easily stretch into days of back and forth to reach a consensus.

Throw in a third person and now you have 3 people trying to asynchronously synchronize on a desired outcome.

You could say "ok, I'll just do something else while waiting on the review" but then you introduce new problems - more context switches - the longer code goes unmerged, the more conflicts can build up - unmerged code can block other things

Post reply on HN