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

Pair programming reminds me of the issue of trying to pair up for video games. Either you find somebody much better than you, or much worse. Because the spectrum is large, the chance of a good match is nil.

In programming the spectrum is larger. When I've been asked to program with somebody, its always been a terrific drag on my productivity. I crawl thru the day, trying to be nice, and when they go the hell home I stay late and do my real work.



I like to pair with people who are as good, but I'm also happy to pair with people who are much better or worse.

When it's somebody much worse (e.g., somebody new to my code base) then I'll spend a lot more time driving. As they see what to do, they jump in. Sometimes I'll force them to jump in regardless, so that they learn by doing.

That's a short-term personal productivity hit, but for me it has always been a long-term team win. There's no faster way to get somebody up to speed. And the sooner they learn The Right Way to do something, the less I'll have to clean up their novice WTF-bombs later.

When it's somebody better, that's pure fun. I learn a ton, I get to see somebody good at work, I pick up tricks, and I end up with a detailed understanding of a colleague's strengths.


In a pair-programming context, what does "my code base" mean?


Good question. I could better have written that as something like "my team's code base".


All well and good, but there is actual work to get done. In the short term, I will get more done without the friction of a 2nd person to tutor. Much more work. Order of magnitude more work.


In the short term? Sure, in the short term you don't need tests, either. Or readable code. Or version control. Or colleagues. Or multi-letter variable names.

Any software development approach works in the short term. In which case, do what you want. But if you're looking for a sustainable approach to building a product, sometimes you have to sacrifice short-term personal productivity to gain in the long term.

Also, "order of magnitude" is a sign you're doing it wrong. Worst case for me is circa a 30% hit; if somebody is sufficiently novice, then they're mainly along for the ride while I code and explain as I go.


then you need to confront your situation and resolve it satisfactorily, because staying in late to get your "real" work done is means to an end, remember you have a "life"!


Kind thought, thank you. But sometimes my life IS my startup, and thats the choice I have made.


I was only referring to your bad "pair programming" experience, in that you felt it held you up from actually getting stuff done, that's just wasted effort.

However, my experience is that pair programming would work well in a senior/not as senior pairing, with the caveat, you need to have capacity on your projects to roll with this also technique.

regarding you choosing to sweat on your startup, fair play thats your choice, and possibly a good one if that's what you are passionate about. hopefully your end goal/mission is not just to make loads of money though!




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

Search: