Hacker News Reader

Comment by mbustamante | Hacker News Reader

every software company in the US is using pair programming ? is that wrong not having pair programming ?

No, not every company uses it, nor is it good for every company or circumstance. It is just a smell that the developers do not believe that working with someone else will help them increase their quality or speed. Some developers really are fast enough that it would slow them down to pair, but then generally, their slower team members might be hugely benefited by just a few hours a week of pairing. So it is a trade-off, do they go fast alone, or go pretty fast with a partner, and increase the _total_ productivity over time?

Pair programming is a great way to get new developers up to speed with the code-base, but the team that is going to be using it long-term needs to apply it with discipline.

I have always thought the concept was great, but I have struggled with how to implement it.

My experience: pair programming usually degenerates into having a human version of the annoying syntax checker prevalent in previous versions of Visual Basic, which required you to close the dialog and then fix the error before allowing you to move to another line. "Whoops, you forgot a semicolon there." "Are you going to close that open brace?" YES I'M GOING TO CLOSE IT I WAS GETTING TO THAT ASDFGHJKL;

IMHO that's either the navigator not knowing any better, or wishing he was the driver, or just being a jerk. The navigator's job isn't to focus on the nitty-gritty, that's what the driver is doing. The navigator should instead, since he's free to think more and look around, keep his eyes on the bigger picture. If the navigator is more skilled or experienced than the driver, then the navigator should be that much more patient and respectful.

That honestly does happen at first, until you get used to the other person a bit more, then the real speed happens.

Once you really are switching every few minutes, and you learn to trust the other guy to figure that crap out himself, then you can stop watching his semi-colons and start watching ahead for what you are going to do when you get your turn to drive. I have worked with someone like that, and the effect was profound, we would get done sometimes 4-5 days of low bug count, high quality work each day. You have to learn to disengage just a bit and start actually thinking about how his work fits in the big picture, and what you are going to do next, not his spelling errata.

My preferred method for training right now is "promiscuous pairing" http://www.google.com/url?sa=t&rct=j&q=&esrc=s&#...

As for hardware setup, the best I have used is: machines with cloned monitors, two mice, and two keyboards, both side by side so the developers can talk in low tones and not bother anyone else. I do this now at work, and it is a lot of fun, and it really averages to be that we get done more than twice what we would work normally alone.

@JackMorgan and @dmiladinov, you two have eerily similar timing and views on this one :) Any chance you're co-workers and happen to know Steve?

Well, I am Steve, the author, and yep, we used to work together a few years back.

Although I haven't had a chance to try this myself, I've been hearing lots of good things about the practice known as "Promiscuous Pairing". Arlo Belshee wrote a paper about it here: http://csis.pace.edu/~grossman/dcs/XR4-PromiscuousPairing.pd..., and I found an insightful blog post about someone else's real experiences with it here: http://www.semantikoz.com/blog/2012/03/25/promiscuous-pairin...

Reply on news.ycombinator.com