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

171–180 of 180 posts

Re: Against Pair Programming

#171

Post by calsy »

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…

Despair all you like. Pair programming stinks.

You can pretend it’s a magical experience where all parties are teaching and learning and having a wonderful time.

In the real world it’s an inconvenience where one person invades your personal space, hovers over your shoulder on your desk with no space as you awkwardly work through who knows what and establish a pattern of dominance as one person clearly knows more than the other and will just do the work themselves while the other watches OR question every single thing typed to the bemused person at the keyboard. No personal bonds are formed during this intrusive process.

Re: Against Pair Programming

#172

Post by girafffe_i »

Empirical metrics would help.

I personally love working with other people vs alone, but there's no meta-analysis of all the qualitative and quantitative netsum effects of it.

Here's a random meta-analysis I found that looks at correctness, quality, and time https://www.researchgate.net/publication/222408325_The_effec... that found pair programming is "not uniformly beneficial"

There's so many more variables that have more qualitative outcomes that make anecdotes baseless and throwaway.

If you sit with people and share experiences, at some point you'll either click, or get so frustrated that you'll start being real and talk through frustrations to help you work with people better.

The camaraderie or conflict resolution skills learned could have force multiplying effects latter.

Who cares about efficiency, I like working with people and making friends at work. Why the hell do you want to work by yourself, especially remotely.

Re: Against Pair Programming

#173

Post by kentrado »

rr808 wrote: post #162
usefulcat wrote: post #157

Earlier quoted context omitted.

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

> You basically can't/don't ever slack off. I think this is the best part of PP, its a great way to avoid procrastination.

That's a good thing for the company. It's a horrible thing for the employee.

Re: Against Pair Programming

#174

Post by watwut »

travisjungroth wrote: post #161
watwut wrote: post #116

Earlier quoted context omitted.

> In that case explaining why you like anything is a way to shut people up who don't No. It is just that specifically agile has a way to responding to people who dont like something with very very handwavy explanations that feel good, but dont really mean anything. Explaining why you personally like something is entirely different kind of communication. Explaining why you think something works well is also different.…

> Why rally racing and not any of the other races where competitors are alone? Why not soccer team for that matter? That seems closer to development then any vehicle racing anyway. There seems to be two directions of analogies here. One is arguing from subject to analog. “Programming is like rally car driving so we should act like they do.” Pretty crummy argument. I’d have no answer to your “why rally car?” question.…

> I’m just saying they have enough shared attributes that I can map how they’re similar and you may find that useful for understanding.So why rally cars? Because that’s the context that has the most similar method as the one I’m talking about

It is fair to guess that nearly no one here ever sat in rally car. We know it has navigátor, but we don't actually know what navigator exactly does. And I genuinely don't see many similarities. It seem to be more about split second decision making in situation where you need to speed up or slow down toward turn.

Re: Against Pair Programming

#175

Post by lkois »

cudgy wrote: post #153
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 inp…

It was just me and the more experienced guy, and we finished what he was working on. The other guy was busy with other things, and never had a similar induction of his own. When I started to work with him after those 2 weeks, it was very apparent that I had caught up, and likely surpassed his ability with the system.

And given the highly unintuitive nature of that system and the rushed training, there was plenty of room left for insight and input without requiring the same initial period of confusion and frustration that caused him and the other devs to have such a negative and lasting view of the system.

And more generally, I'm not sure why you feel the need to poke holes and find potential negatives in what was a positive training experience. Especially when what you've said could apply to any kind of training, and disregards the situation as described.

Re: Against Pair Programming

#176

Post by lkois »

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.

He was quite diligent about taking regular and appropriate breaks. Partly in response to having worked through too many lunches prior.

Brain sag still occurred though.

Re: Against Pair Programming

#177

Post by lkois »

ramesh31 wrote: post #117
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…

>The irony is, this guy hated the needless difficulties of the job, but was so happy about quitting that he made my onboarding pretty great, and so I didn't feel his level of frustration while continuing on in it. Sounds like a real professional, you lucked out. The standard case is to just inherit that garbage and pray to god nothing breaks when you touch it.

Haha yea I did. Though he even acknowledged that if he wasn't quitting, I'd have had a grumpy coworker instead of any training.

Re: Against Pair Programming

#178

Post by travisjungroth »

watwut wrote: post #174
travisjungroth wrote: post #161

Earlier quoted context omitted.

> Why rally racing and not any of the other races where competitors are alone? Why not soccer team for that matter? That seems closer to development then any vehicle racing anyway. There seems to be two directions of analogies here. One is arguing from subject to analog. “Programming is like rally car driving so we should act like they do.” Pretty crummy argument. I’d have no answer to your “why rally car?” question.…

> I’m just saying they have enough shared attributes that I can map how they’re similar and you may find that useful for understanding.So why rally cars? Because that’s the context that has the most similar method as the one I’m talking about It is fair to guess that nearly no one here ever sat in rally car. We know it has navigátor, but we don't actually know what navigator exactly does. And I genuinely don't see ma…

You don’t need to have sat in a rally car. The split second decision making is the context, not the method. The context doesn’t have to match perfectly. They just share the attribute of “high cognitive load”.

Did you read the link I posted? The essence of the idea is you have one person who takes physical action, makes small decisions and take orders. That person is called “driver”. You have another person who makes larger decisions and gives orders. That person is called “navigator”.

The dynamic I just described is true of rally car driving and strong style pair programming. It’s not true for most pair programming or most other types of driving.

Re: Against Pair Programming

#179

Post by tremon »

falcolas wrote: post #110
tremon wrote: post #93

Earlier quoted context omitted.

No, they would need to communicate about the ideas and thought processes behind every individual line of code. If not now, then the next time there's a bug in said lines.

> ideas and thought processes behind every individual line of code I realize you're being hyperbolic (at least as hyperbolic as the parent), but this is one of the big hangups of pair programming for me: waiting for folks to get through boilerplate. Let's talk ideas and thought processes about the important (or at a minimum non-boilerplate bits of) code, not an entire programming session. "Alex, what were your though…

"Alex, what were your thought processes that lead you to a for loop here, rather than a {while loop/list comprehension/map operation/linq expression}?"

Re: Against Pair Programming

#180

Post by tlarkworthy »

mrtranscendence wrote: post #112
tlarkworthy wrote: post #109

Earlier quoted context omitted.

Maybe they will have some helpful suggestions or techniques that will speed up that process...

Maybe? But on the whole I tend to be pretty fast, just a bit hyperactive. I suppose I mostly feel as if pair programming would stifle the ability to experiment with every bit of code while I go, and cause me to have to plan everything out in a way that's unnatural to me. Maybe I'm wrong.

I find pair programming very good for transmitting workflow improvements. It's not the kind of thing that makes it to blogs
Post reply on HN