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

131–140 of 180 posts

Re: Against Pair Programming

#131

Post by shlurpy »

aerojoe23 wrote: post #96

As an industry we seem to think hard and make proclamations about programing. Where we should be thinking hard and making hypothesis and testing them. Turns out some people have been doing this and some people put it into a nice book. They conducted systematic reviews of the literature around many software development questions. The book (I know about anyway) is: Making Software: What Really Works, and Why We Believe…

Agreed. We've had an entire scientific revolution since the days of arguing about humans as a fatherless biped or the angels that can fit on a needle point.

Articles like this that provide nothing but rhetorical arguments feel pointless in an era where tools like statistics and hypothesis testing exist.

Re: Against Pair Programming

#132

Post by projektfu »

watwut wrote: post #116
toqy wrote: post #92

Earlier quoted context omitted.

> That analogy is just yet another way how to shut up people who dont like the process. In that case explaining why you like anything is a way to shut people up who don't

> 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 not soccer team for that matter? That seems closer to development then any vehicle racing anyway.

Perhaps unintentionally, a good analogy for traditional software teams. Eleven players, one or two stars, the other players mostly looking good because they can pass the ball to the top players.

In the end, all analogies suck. Pair programming is a pretty unique situation in the workplace, it works great for some people, others will never like it. It worked for me because I was kept on task. It may have slowed down the top performer but that person appreciated the company. Overall I think it made our team of 8 at the time more productive than they’d have been with separate assignments, and it really helped with team cohesion.

Re: Against Pair Programming

#133

Post by skeeter2020 »

Veuxdo wrote: post #97
IanCal wrote: post #65

Earlier quoted context omitted.

Yeah it would be weird to me if programming is some unique task where two people solving a complex problem together is a bad thing. I'd not done it much in the past but recently seen it done more and participated more - each time it's been useful. I paired to deploy some work, and having both of us work together was really helpful as we could talk through issues we were seeing as we went and it taught me more about i…

What's weird and unique about work that one person can do better than two? Novel writing is complex, chess is complex, art is complex. Individuals do these things all the time.

> Novel writing is complex, chess is complex, art is complex.

Well one thing you need to consider is that most software is not written in small, artisian batches but at scale. Pairing is one way to promote doing development and all the things you mention at a greater capacity than the individual.

Re: Against Pair Programming

#134

Post by bluefirebrand »

sascha_sl wrote: post #73
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…

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.

Re: Against Pair Programming

#135

Post by skeeter2020 »

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…

how about that we're also social creatures? Devs get a bad wrap as anti-social intraverts who want to sit in a dark room alone all day, and yes there is a time for that, but I absolutely love learning from someone directly AND sharing something I know. Sometimes I wonder if the resistance to pairing is because of the weaker relationship between the individuals and not the act itself.

Re: Against Pair Programming

#137

Post by skeeter2020 »

shepardrtc wrote: post #43
vector_spaces wrote: post #14

Earlier quoted context omitted.

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

> 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. Early in my career - in a 4 person shop - I had a manager that mandated it. He was very extroverted and always talking. Pair programming was very difficult for me because my attention always shifted to him and any complex thoughts about the code would be wip…

this is more like what the author described as pairing than what I would hope it is like. I view the ideal (and try to make my sessions) more like translating two people working at a whiteboard to programming. It's tough to get it right though.

Re: Against Pair Programming

#138

Post by pictur »

The worst of pair programming, in my opinion, is that people come to a consensus among themselves, as the author stated. at some point it turns into a mechanism where each group defends its own opinion.

Re: Against Pair Programming

#139

Post by Veuxdo »

skeeter2020 wrote: post #133
Veuxdo wrote: post #97

Earlier quoted context omitted.

What's weird and unique about work that one person can do better than two? Novel writing is complex, chess is complex, art is complex. Individuals do these things all the time.

> Novel writing is complex, chess is complex, art is complex. Well one thing you need to consider is that most software is not written in small, artisian batches but at scale. Pairing is one way to promote doing development and all the things you mention at a greater capacity than the individual.

Maybe? Dividing up the work is the other, traditional, way to work at scale. It hasn't been shown that pair programming is more effective.

Re: Against Pair Programming

#140

Post by walljm »

mrozbarry wrote: post #84
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…

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 also find that pair programming can be a great way to train programmers in areas of knowledge they may not be up to speed on, to mentor junior programmers, or to just learn from your peers as they approach problems from different perspectives.

i also find paring to be useful when troubleshooting or working on a hard to find bug.

pairing shouldn't be the norm, but it can certainly be useful.

Post reply on HN