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."
Like many workplace practices, it's something worth trying, but not something to be trumpeted as "the way" to do things. Some people get on with pairing, some don't. And it's OK either way. Likewise, there are writers who work in pairs, but many who do great work alone. There are architects who work in groups and alone. So it goes for software developers.
Where it goes sour, however, is when people who find pair programming valuable start tarring anyone who doesn't do it as being error-prone slackers.
I know it's just a summary and all, but it makes me feel vaguely sad that out of all of the things you can say about him, Kent Beck is tagged as a "Facebook programmer."
PRO-TIP: the other guy was the compiler.
That is because new programmers don't have experience solving problems, and end up getting stuck spinning their wheels. For them, programming is the challenge. For more experienced people, the programming is trivial, it is the design that is a challenge.
while(1) attack(People.Sandy);
It's not for everybody - nothing is - but it's definitely worth trying with an honest effort.
Dare to Hope. Prepare to be Disappointed.
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...?
After you live and work through 10 or so silver bullet fads you'll get a bit jaded at "oh god not yet another silver bullet that'll magically fix everything if we just change everything and hire some expensive consultants".
http://en.wikipedia.org/wiki/No_Silver_Bullet
My main whine about pair programming is its a bastardization of ye olde master/apprentice. Oh so close to being correct, yet still miss the target. That's worked in about a zillion other fields for only about a zillion centuries. I learned a lot as an apprentice from some good masters and taught a few apprentices as a master, hopefully well. Pair programming claims master/apprentice inevitably leads to "watch the master" where the apprentice sits around and learns nothing. That's wrong; its not an inherent effect of master/apprentice, it's an inherent effect of shittymaster/apprentice. It does correctly show that having a con man or moron as master doesn't work, or maybe the older the programmer is the more important it is that he not be an idiot. Also its the apprentice's job not to be passive... ask why, ask how it works, ask what other options exist, etc.
I suppose you can't charge $xxx/hr as a consultant or book author merely by telling the boss to set up something like a medieval blacksmithing guild, gotta come up with some new twist on the old story.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
we can talk about it in complete detail when it makes sense, i don't need to smell your farts
You might change your mind if you were working with me. My farts smell like roses.
Theoretically pair programming is supposed to pair up programmers with other programmers, not with management.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I think we can all see where this is going.
Programmer centipede.
You know I'm right.
Or drive the few women in tech far far away....
People in cars cause accidents....accidents in cars cause people
Let's face it...this is yet another iteration of the dance we've seen before. Extreme Programming, Agile Programming, and so on. Companies keep hoping that there's a methodology that can be applied to the process of coding and development that will homogenize their workforce, allowing them to look at coders more like cookie-cutter individuals. There are multiple drivers behind this: the difficulty of assessing a programmer's talent during the recruiting process, the desire to use cheaper resources, especially in outsourced business models, and the challenges that result from coders who turn out not to be a good fit with their role. But at the end of the day, coding is a creative process, and creativity fares poorly under standardized, one-size-fits-all models.
For your security, this post has been encrypted with ROT-13, twice.