Slashdot Mirror
The Programmers Go Coding Two-by-Two — Hurrah?
theodp writes "The Wall Street Journal reports that pair programming is all the rage at tech darlings Facebook and Square. Its advocates speak in glowing terms of the power of pair programming, saying paired coders can catch costly software errors and are less likely to waste time surfing the Web. 'The communication becomes so deep that you don't even use words anymore,' says Facebook programmer Kent Beck. 'You just grunt and point.' Such reverent tones prompted Atlassian to poke a little fun at the practice with Spooning, an instructional video in which a burly engineer sits on a colleague's lap, wraps his arms around his partner's waist and types along with him hand over hand."
But most of the elder wizards of the programming community (at least the ones I know) tend to shy away from the pair programming mentality. Younger folks (especially people in their 20s) don't seem to mind as much.
I wonder if this has something to do with the nature of the people who went into programming 20 years ago (compared to today), or what...?
"Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth
so it's eXXXXXTreeme programming again?
couldn't they at least fucking re-use the term.
oh and it's not so bad for some small crunch period.. but for longer periods it really shits on my slashdot browsing habit.
am I now officially old? since they tried selling us this XP shit back before I dropped out of uni.
world was created 5 seconds before this post as it is.
It's not for everybody - nothing is - but it's definitely worth trying with an honest effort.
Dare to Hope. Prepare to be Disappointed.
But most of the elder wizards of the programming community (at least the ones I know) tend to shy away from the pair programming mentality. Younger folks (especially people in their 20s) don't seem to mind as much. I wonder if this has something to do with the nature of the people who went into programming 20 years ago (compared to today), or what...?
Or it has something to do with experience. The elder programmers have seen many programming fads come and go, many claims for the "one true way" to greater efficiency and reducing bugs. Like most fad/pop things, pair programming probably worked in a specific environment, with specific people doing a specific type of task ... but is probably not a universal solution. It is merely hyped as such by the "training" industry, book sellers, etc.
Elders may realize when working in pairs will help and when it will not. I've seen plenty of instances when elders call in a peer for an hour or two for a particular bit of code and then part when returning to the more mundane parts of the code. Or ask a peer to review a bit of code they just wrote.
Great points all. I'll add:
5. It keeps you honest. Coding is full of temptations to cut corners. But you're less likely to cut that corner if someone else is watching -- and you won't let a colleague do the kind of lazy things you'd do yourself.
YMMV. In my experience, it makes me cut corners more, because I feel like I'm wasting the other guy's time if I sit and think hard for a couple minutes about how to, say, rewrite a loop more clearly.
But that's part of one's job, to think about those things and when to do them and when not to. You are teaching the junior person how to thing about such concerns, and hopefully many others (instead of just let's get this shit to compile asap!!!!). Quality coding is not just banging the shit out of the keyboard, and anytime a vet helps a junior cross that mental chasm faster, it helps both the junior and the company's bottom line.)
I have seen a problem in that in the time I have done pair programming.
When I am the 'seasoned vet' I get quickly frustrated by the slowness of the person who is writing. On the other hand, when the writer is more senior than I am, oftentimes I just cannot follow what he is doing, if he goes too fast (like when doing Vi-editing).
This maybe except with one particular very good senior who was saying out loud what he was doing *as* he was doing it.
Ubuntu is an African word meaning 'I can't configure Debian'
That is the most difficult pairing you can make unfortunately. Either you put the vet as the driver and the junior will simply not follow or get bored. Or you let the junior drive and then it becomes a dictation. In both case, the junior brain shut down and it relies on what's written/dictated and stop thinking for himself.
You want junior dev to struggle a bit on their own so they have the opportunity to evaluate various options. That process is enhanced in pair with another junior developer. Immediate feedback from a more senior dev is in my experience slowing the learning process and killing the creativity of the junior.
Yes, I've worked with people who are great at pair programming and those who are not so good. I find that when working with someone who really gets PP you end up with two programmers (or more!) working together, both of them on the same page, catching mistakes and improving how the code is written.
When working with someone who just starts coding and expects their partner to magically understand what they've decided to do then it can be impossible to keep up or figure out what on earth they're doing. At that point you have a programmer programming and another programmer wasting their time scratching their head.
PP works wonderfully when you pair people up correctly and train everyone involved how to effectively work like that, but if you don't then you waste resources and frustrate your coders.
Silly rabbit
You used the word, "mentoring". It occurs to me that people have been doing this in virtually every trade for centuries in more traditional apprenticeships.
I was in a situation similar to this as a programmer. Nobody had planned for us to work in pairs, it just worked out that way. The bit in the summary about the two of you learning to basically read each others' minds is pretty accurate.
One guy tends to introduce the more creative, interesting ideas, while the other (probably more experienced guy) sees when you're missing the forest for the trees. The end result is, hopefully, more impressive work that's not so impressive that it fails at basic functionality.
It worked out really well for us. Of course, YMMV.