For Writing Software, a Buddy System • Hacker News Board

Re: For Writing Software, a Buddy System

#21

Post by aaronblohowiak » Sun, Sep 20, 2009, 8:04 AM UTC

sandaru1 wrote: post #14

aaronblohowiak wrote: post #13

Earlier quoted context omitted.

Actually, it is precisely the experimentation / hunch-following times where I've found the biggest productivity gains -- bouncing ideas around with another smart and creative person is a lot more stimulating and effective than the code - compile -check loop!

"code - compile - check" - I'm assuming that you are talking about coding/algorithm bugs. What I'm saying is, lets say you want to find a way to update a web page with live data(http push?). Then you do a brainstorming session with others and get some ideas(comet, bosh, xmpp, etc). If you want to see which technology fits your product most, then it would be a good idea that each person is spending time on different i…

for bugs, i find rubber-duck pairing tends to get most of the advantages of pair-programming. for the c-c-c, i was just meaning toying around with new code "ideas". I suppose parallelizing approaches is a good optimization for a certain class of solving strategies, but I was more meaning to imply that your coworkers may have insight into other things (one of my coworkers is all about python, another used to do natural language stuff and i happen to have a degree in psych, so we all bring a different perspective to the same problems, and that is useful.)

Re: For Writing Software, a Buddy System

#22

Post by obiefernandez » Sun, Sep 20, 2009, 2:42 PM UTC

The article glances over a lot. We pair-program on production code over 95% of the time. Driving duties alternate every few minutes or even seconds. Pingpong programming is common. It's all facilitated by having dual keyboards and mice hooked up to the workstation. Occasionally the pair splits up virtually. Each half of the pair has their MBP sitting there on the desk next to the 30" shared workstation monitor. If the driver is taking care of a mindless task (just typing) then the non-driver can switch their attention to their own screen for whatever, but still be aware of what the driver is doing. Examples of windows you have open on your MBP while pairing are: Harvest for details time-tracking, Campfire to communicate with stakeholders and other devs, pivotaltracker to refer to story details, API references, etc.

On the people front, we do our best to only hire experienced devs that will like the culture and fit in. We're a boutique shop, so we can be very picky about who we hire. Candidates have to pair with us onsite for at least a week before the team decides whether to hire. We've hired qualified interns, but don't hire apprentice or junior-level folks. Occasionally we do extended pairing matchups with client developers in our office, but they have to fit in culturally for it to work.

I think pairing all the time is one of our most important competitive advantages. My teams produce some of the highest-quality code I've ever seen in 15 years in the biz. We are able to effectively leverage XP-style client acceptance in our process because our code is so defect-free.

I'm proud of what we've created at Hashrocket, but usually try to stress the importance of context and talent in making it work. Pairing all the time is one of those things where I have to advise Agile idealists that it probably won't work for them. :(

Re: For Writing Software, a Buddy System

#23

Post by catch23 » Sun, Sep 20, 2009, 6:35 PM UTC

haupt wrote: post #3

'Pair programming' would get a bit frustrating, don't you think? I suppose productivity would greatly depend on the personalities involved.

I usually let who ever is "driving" just write the damn code. He might write poorer code than I, but we're just trying to solve story cards quickly and if the tests pass, I don't complain. I usually only perk up when I notice logical errors, or other places in the code that we'll have to change when my pair refactors something.

Re: For Writing Software, a Buddy System

#24

Post by catch23 » Sun, Sep 20, 2009, 6:38 PM UTC

brown9-2 wrote: post #5

I've never experienced pair programming, and I'm dubious that I'd work well in it, but I'm amazed at employers that would prevent employees who were interested from working in pairs.

The best thing that comes out from it is the peer pressure to stay focused. Even if your pair doesn't know anything about programming, just having him sit there and watch you will make you at least twice as productive so that you don't end up reading Hacker News while your unit tests are running!

Sometimes we'll be so engrossed in the engineering, that neither of us will remember that restaurants close at 9pm and we have to stop to eat.

Re: For Writing Software, a Buddy System

#25

Post by gommm » Sun, Sep 20, 2009, 8:14 PM UTC

One thing I like doing when pair programing is have the navigator code up the specs for the new feature while the driver is implementing... I find it rather efficient at catching bugs...

Re: For Writing Software, a Buddy System

#26

Post by anamax » Sun, Sep 20, 2009, 8:29 PM UTC

obiefernandez wrote: post #22

The article glances over a lot. We pair-program on production code over 95% of the time. Driving duties alternate every few minutes or even seconds. Pingpong programming is common. It's all facilitated by having dual keyboards and mice hooked up to the workstation. Occasionally the pair splits up virtually. Each half of the pair has their MBP sitting there on the desk next to the 30" shared workstation monitor. If th…

> Candidates have to pair with us onsite for at least a week before the team decides whether to hire. We've hired qualified interns, but don't hire apprentice or junior-level folks.

How do those people get the time to do the week with you? Do you only hire folks who are currently unemployed? (Full time for a week means that they're not interviewing elsewhere.) Do folks use vacation (or unpaid) time to see if you'll take them on?

Re: For Writing Software, a Buddy System

#27

Post by DanielBMarkham » Sun, Sep 20, 2009, 8:36 PM UTC

obiefernandez wrote: post #22

The article glances over a lot. We pair-program on production code over 95% of the time. Driving duties alternate every few minutes or even seconds. Pingpong programming is common. It's all facilitated by having dual keyboards and mice hooked up to the workstation. Occasionally the pair splits up virtually. Each half of the pair has their MBP sitting there on the desk next to the 30" shared workstation monitor. If th…

I think pairing all the time is one of our most important competitive advantages.

Thank god somebody finally makes a rational case for XP practices.

So much of the XP adherents amounts to hand-waving and foot-stomping. It's good to see somebody say "this is making us more competitive"

I've yet to see a similar argument made about TDD. It may be that TDD makes more sense as an add-on to pair programming (with ping-ponging) than as a stand-alone practice.

Re: For Writing Software, a Buddy System

#28

Post by duncanj » Sun, Sep 20, 2009, 8:44 PM UTC

xcombinator wrote: post #19

My experience with pair programming: It is so great when the other person is very good/smart at programming. You sense that your work is way more than the sum of the individual parts. It is like an explosion of creativity because you don't stop when you have a block and the other has not, or he has a block and you have not. It is not great when the other person is not good/smart. You make all the work, the other can…

My experience differs. I found it much easier to pair with poor/inexperienced programmers than to encounter their code later without having paired. By letting such a programmer do the driving and critiquing as they went, I felt like they were learning useful things and I was saving myself a lot of trouble in the future.

Re: For Writing Software, a Buddy System

#29

Post by obiefernandez » Sun, Sep 20, 2009, 9:30 PM UTC

anamax wrote: post #26

obiefernandez wrote: post #22

The article glances over a lot. We pair-program on production code over 95% of the time. Driving duties alternate every few minutes or even seconds. Pingpong programming is common. It's all facilitated by having dual keyboards and mice hooked up to the workstation. Occasionally the pair splits up virtually. Each half of the pair has their MBP sitting there on the desk next to the 30" shared workstation monitor. If th…

> Candidates have to pair with us onsite for at least a week before the team decides whether to hire. We've hired qualified interns, but don't hire apprentice or junior-level folks. How do those people get the time to do the week with you? Do you only hire folks who are currently unemployed? (Full time for a week means that they're not interviewing elsewhere.) Do folks use vacation (or unpaid) time to see if you'll t…

> Do folks use vacation (or unpaid) time to see if you'll take them on?

Yes, which also serves as near-concrete proof that a candidate _really_ wants to work with us.

Re: For Writing Software, a Buddy System

#30

Post by ams6110 » Mon, Sep 21, 2009, 3:21 AM UTC

I quit my last job because of pair programming. I absolutely cannot think with another person sitting next to me at a desk. It's the absolute worst experience I've ever had as a developer.