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

91–100 of 180 posts

Re: Against Pair Programming

#91

Post by travisjungroth »

watwut wrote: post #86
toqy wrote: post #39

Earlier quoted context omitted.

> I'd say it's more like having a second pair of eyes while you're doing a tricky reversing maneuver. I’ve always liked the rally racing driver/navigator analogy for explaining pair programming. It tends to go better if you generally follow those roles when doing it too.

I don't think that is good analogy. Driving race with driver and navigator are in completely different then anything related to programming or even pair programming. That analogy is just yet another way how to shut up people who dont like the process.

The way some people pair is really more similar to rally driving than you give it credit. I hate backseat driver style pair programming. Strong-style is very different and more like right-seat (I’m in the US, so let’s say not-driver seat) driving. https://llewellynfalco.blogspot.com/2014/06/llewellyns-stron...

Re: Against Pair Programming

#92

Post by toqy »

watwut wrote: post #86
toqy wrote: post #39

Earlier quoted context omitted.

> I'd say it's more like having a second pair of eyes while you're doing a tricky reversing maneuver. I’ve always liked the rally racing driver/navigator analogy for explaining pair programming. It tends to go better if you generally follow those roles when doing it too.

I don't think that is good analogy. Driving race with driver and navigator are in completely different then anything related to programming or even pair programming. That analogy is just yet another way how to shut up people who dont like the process.

> 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

Re: Against Pair Programming

#93

Post by tremon »

Veuxdo wrote: post #50
tweakimp wrote: post #17

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

> 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. That's assuming two people pair programming would otherwise need to communicate about every individual line of code.

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.

Re: Against Pair Programming

#94

Post by alistairSH »

I never considered pair programming as a tool simply to increase raw velocity. For me, it's almost always been a pedagogical tool - it's an effective way to up-skill a developer who's learning (both young developers and experienced developers learning a new skillset).

I would never force it on my team. But, given the task "teach Bob X", they often come to some form of pair-programming on their own. I usually only suggest it when learning becomes a roadblock.

Re: Against Pair Programming

#95

Post by calsy »

Pair programming stinks, always has always will. Its another mindless initiative managers come up with because some person in the organisation who subscribes to the Agile cult (there is always one) wont stop going on about it.

Like most things Agile, it treats the developer as a child who cant be trusted to get things done. It's grade school where teacher tells you it's time for 'pair programming', yeahhhh. Usually it's at the worse possible time, and it's just another distraction in days filled with distractions that stop you doing anything meaningful.

If people need to work together, they'll do it naturally like any ordinary adults who are asked to complete a task.

Re: Against Pair Programming

#96

Post by aerojoe23 »

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 It

and Chapter 17 address pair programing.

It has been a while since I read it, and it is a little thick to jump in and read it to make sure I'm 100% accurate ATM. But the summary I took away for my work environment is that, you get the same productivity with 2 devs working by themselves vs 1 pair, with a lower defect rate. I'd like to quote things directly but I'm not investing that much time right now.

Pair programing IMHO is skill that needs to be learned, and it is a different skill depending on the type of pair you have at the time and what you're trying to do

Re: Against Pair Programming

#97

Post by Veuxdo »

IanCal wrote: post #65
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…

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.

Re: Against Pair Programming

#98

Post by agentultra »

I don't want to pair program full-time but this post is absurd. When I do pair program I find the process engaging. My partner is there to bounce ideas off of and the experience, for me, has generally been jovial. Code written in a pair programming session tends to get reviewed faster as it contains the assumptions and direction of more than one person on the team, leading to fewer surprises and questions.

We're knowledge workers and sometimes having someone to bounce ideas off of and work alongside can be useful to get the creative juices flowing.

Post reply on HN