Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Aside from physical, eyesight, accessibility, noise, etc. problems, I pretty much can't stand pair programmming. It's good for social bonding and instructing noobs, but my work is hardly up to snuff.

I can't "navigate" someone moderately competent because it takes me forever to stuff a pile of someone else's code into my head. I have to keep scrolling here and looking there, which I can't do without a separate keyboard and monitor. I want to navigate from an extra computer so I can flip through the code, look up docs, and so on. But, by gum, that's not "pair programming." Hence, the only thing I'm good for as a navigator is catching syntax and spelling errors, which is something an appropriate editor or IDE can do.

And I can't accomplish much while I'm "driving" because either I have to spend all my time explaining everything to the noob, or I'm not allowed time to think. If I stare into space or scroll around a bit, the navigator thinks I'm stuck and feels compelled to chatter away with advice or questions or something. And unlike the author's "Progammer Man," the code I produce solo in the Zone is better than the code I produce in a pair out of the Zone. The best "navigator" is someone who watches awhile then gives up and "pairs" with someone else! No, I take that back. Apoorva is a decent navigator. He mostly just sits there and makes a few pleasant quips, occasionally raising an insightful question. I guess I'm very, very finicky about navigators.



Seems like your main criticism revolves around being chained to a newbie as half of the pair - I'm not sure pair programming is designed to work well in that setup. It's pair programming, not pair mentoring, and if there's a huge disparity in skill level, then it'll feel like a drag. Yes there's an amount of mentoring in good pairs because everyone's at least slightly better in at least one different area than their partner, but similar enough in skill sets that you can build upon the differences when needed, rather than constantly bringing the partner up to par.

The places I've seen it work seamlessly has been where it averages out the work to a consistent level, whether all intermediate coders that no longer make rookie mistakes or all advanced ones that no longer slow down for newbie speed bumps. I've even seen pairs attack projects in programming languages they've never worked with before. I was brought in to Pivotal for an afternoon or two to give Flex/actionscripting advice to the programmers working on a friend's prototype site and they didn't need my help at all, I was happy to see that they knocked it out just fine.

On a side note, I just tried out pair designing this week (instead of programming) and it was a really interesting experience. You could see that we each had different focus (me = interaction designer, partner = visual designer) and that helped compliment our work rather than act as a source of friction. And not to get into a toolkit debate but we also shared similar philosophies about hating Photoshop and long design cycles, loving Fireworks and quick clickable prototypes, etc.


Pair designing/programming/whatever seems to work best when the pair has complimentary skill sets rather than different competency levels of the same skill set. We have been "pair designing" for a while with much success.


Who's "we"? I'd like to collect stories of pair designing in action.


Speaking of skill level, it occurred to me last year to offer to be "roving guru" (sounds haughty) or "roving consultant" or simply "Rover" (woof!) when we have an odd number of developers. This works out nicely for me anyway, and the others are fine with it. I have no idea what this does to our velocity because we are, unfortunately, very disorganized and don't keep track. (I shan't bother to explicate.) I do enjoy teaching and mentoring people, as long as that's the real plan. And the roving helps me tolerate the noise level in an open workspace. Maybe because I have to pay attention to all the vocal noise. I have to keep alert to the sound of people calling for assistance or sounding lost and confused.

OMG, I just got an insight. I'm an effective Rover or mentoring "navigator" as long as no one expects me to read. I need to not look at the monitor, not try to read the code or docs or whatever. As long as all I do in the presence of talking people is do my own listening and talking, my brain doesn't turn to complete mush. I noticed long ago that I have almost zero reading comprehension when I read English (native language) aloud. I also remember covering my ears while reading silently when someone else reads or the teacher is talking. Etc. So the big insight is, my reading incomprehension in the presence of speech extends to reading computer code! I have a reading problem (or attention problem, or whatever it boils down to) which frustrates my ability to pair.

That explains why I have such a hard time understanding even a single line of code in most pairing sessions. That explains why, when I'm the "extra set of eyes," all I'm good for is syntax and spelling check (which really should be done by software, not me). Writing code happens to be a lot more of reading what's on the monitor than head's down typing. So, the question is, how am I able to drive okay with insightful and not-so-obtrusive Apoorva? Well, it often doesn't work. But I notice it does work when there's only one other pair in the room and I haul Apoorva and me to the far end. That cuts the other voices down significantly.

Thank you, thank you for prompting me to think this through.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: