For Writing Software, a Buddy System

http://www.nytimes.com/2009/09/20/jobs/20pre.html

by peter123 • 17 years ago

45 33 17 years ago

quellhorst• 17 years ago

Hey Rocketeers, cool that you guys got covered in NYTimes! I was lucky to work with these guys last year. Pairing really does help improve code quality, but I still prefer to code solo or have two separate work streams going at once.

haupt• 17 years ago

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

known• 17 years ago

Pair debugging is very productive.

s3b• 17 years ago

Yes, personality flaws are a problem. Some people are selfish with the keyboard, some always want their ideas to be implemented, some don't coach well, some don't have good personal hygiene, etc. However that said, I still feel pair programming is the best way to do it. Productivity is a lot higher when pairing.

catch232• 17 years ago

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.

foca• 17 years ago

You're missing half the fun, then. Part of the point of code reviews (and pair programming is, at its core, extreme code reviewing) is make sure both write the best possible code, both in terms of being bug free and adhering to company standards.

If you don't care about how the code ends up in terms of structure other for the logical errors, you're doing it wrong (well, according to me anyway, so it's not that big of a deal :P)

wallflower• 17 years ago

> To me, pair programming is the only way to work. Writing code is not only scientific, it’s also a creative process.

I agree with the statement about how programming is creative work, and I disagree with the 'only way to work' statement. Pair programming is a great tool, but it doesn't have to be always used. When you adopt a methodology or process like XP or Scrum, we don't always have to adopt it wholesale - just pick the pieces that work. Pair programming, in my experience is excellent at solving difficult issues under deadline and/or implementing brand new features. For everything else, it may be overkill. Plus, with pairing, it's hard to get your mental breaks in while you simmer a problem in your mind (e.g. check out News.YC).

It's kind of like the concept of scrum rooms. We had a critical iteration and flew everyone in for a conference room-based intense week-long session. We got a lot done - much more than we could have done over WebEx. However, at the end, I wanted to kill the guy with the noisy trackball. Close quarters can become trying over time (extended family meetings anyone?)

Hashrocket may be a notable exception to the norm of programmers working in isolation/cubes (especially in larger companies)

jremsikjr• 17 years ago

> To me, pair programming is the only way to work.

Could've softened that up a bit, sure. I completely agree that not every problem is a nail for the hammer of pair programming. We've developed a very popular and productive pairing environment at Hashrocket.

We have found pairing to be helpful in solving difficult issues. And we have used it to enhance the design of software being written from scratch.

As for the mental breaks, some of us use the pomodoro to coordinate their break times. Others prefer to agree to breakpoints as they come.

We know pairing is not a fit for everyone, everywhere, all the time. However, if you are interested, this is how we do it, it works for us and, we hope our experience helps you.

Cheers!

brown9-2• 17 years ago

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.

catch232• 17 years ago

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.

arghnoname• 17 years ago

I've pair programmed before, and in my experience it's great when the codebase and job at hand is so terrible, that when working individually it's hard to have the will to live, let alone be productive.

In this environment, pair programmed got us both past the logjam we were both experiencing on this codebase and we were able to get things into the sort of shape that working alone became not only palatable but enjoyable again.

We also did some API work together, and I think if you're writing interfaces and the like, working on that with someone who will be using it can be helpful in getting a good initial API out there.

There are also other sorts of programming tasks where I don't feel pair programming was very productive (for me/us anyway).

mynameishere• 17 years ago

Yes, in practice, everybody pair programs, on an as-needed basis. When it's not needed...well, you shouldn't be doing it. I seriously think that non-stop pair programming is just a way to keep people from goldbricking (as the article hinted at the end).

And really, 90 percent of programming is more "typing" than programming because the work is straightforward.

dandelion• 17 years ago

That's an exceedingly ignorant statement.

sandaru12• 17 years ago

Pair programming seems to be good, if you have everything defined. But in reality, you research, experiment, hack things around. You work on hunches and quickly implement them, then gradually improve them, compare the solutions and find the best. Pair programming would be pointless; rather annoying in this case.

aaronblohowiak3• 17 years ago

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!

sandaru12• 17 years ago

"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 ideas.

"brainstorming" is completely different from "coding together", specially coding a hack.

gruseom2• 17 years ago

It works both ways. Sometimes I want to throw ideas around with a partner and other times I want to go deep inside an intuitive thought process. The key is to recognize what wants to happen at any given moment, and to have a culture that respects that flow. It really bugs me when people try to impose a predefined process on that. But it also bugs me when people come up with reasons to say co-programming isn't productive, when experience shows that it clearly often is. (Not that you were doing either of these things.)

ojbyrne• 17 years ago

One of the things I find really effective, and almost never see, is pairing up product managers directly with programmers. Instead of product types going off and holding endless meetings finally resulting in a product spec carved in stone, there's a nice interactive process of product development.

sachinag• 17 years ago

We did exactly this for the two-month sprint for the initial code for Dawdle. I moved into the contracting firm's office, and we did this stuff all day long. It was great; they got a sense for what was "nice to have" and non-negotiable and I traded stuff that wasn't as important (a functioning search; we ended up using SWISH-E, shudder) for stuff that was (user account management). Both sides learned a lot, and I now know that most programmers aren't as good as the people who did that code.

To this day, two years later, our search still sucks, but the basis of that user account management has meant that we haven't had to touch that code in almost two years.

akeefer• 17 years ago

I definitely agree . . . it's a fairly standard "agile" practice to make sure that product managers/"customers" work closely with developers, but it's often not done that way. The bottleneck at my company has historically been around seating; we have an open office plan with clusters of 4-6 desks, but even then you have to make tradeoffs around who sits near who, and we've historically put developers next to developers and product managers next to other product managers so that they could all talk and coordinate with each other. That tends to mean the product managers are just far enough away from the developers that they don't talk much.

For our most recent development cycle (which started about 10 months ago), we finally bit the bullet and split the product team into cross-functional sub-teams we call "pods" consisting of (roughly) 5 developers, 3 QA, and 1 product manager. Having the product manager sit literally next to the developers, instead of 15 or 20 feet away, has made a huge difference in the interaction there and our ability to quickly iterate on features. Instead of just making assumptions when the product requirements are unclear or don't seem to make sense, we have much more of an ongoing dialog all day about how things should work, meaning we waste a lot less time building the wrong thing.

xcombinator• 17 years ago

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 only spot the obvious, and makes the sum way less than individual parts. Feels like an endless drain that won't finish ever.

In world war they experimented with airplanes pilots: creating groups with the best ones, letting other groups with the not so good. It was fantastic for the elite groups, but bad for the mediocre ones.

They mixed groups with good and mediocre people and it made the mediocre turn good, but the good didn't became elite.

So I think this has pros and cons, and is not for everyone.

duncanj• 17 years ago

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.

div• 17 years ago

Do you happen to have a link for that Airforce experiment ? I'm genuinely interested.

obiefernandez2• 17 years ago

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. :(

anamax• 17 years ago

> 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?

obiefernandez2• 17 years ago

> 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.

DanielBMarkham• 17 years ago

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.

gommm• 17 years ago

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...

ams6110• 17 years ago

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.

For Writing Software, a Buddy System

Related Stories