For Writing Software, a Buddy System | Hacker News Reader

For Writing Software, a Buddy System

nytimes.com

45 pointspeter12333 comments

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

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

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

Desperation is the new qualification.

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.

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

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.

That's an exceedingly ignorant statement.

I don't know which statement you mean, and it's a bit unnerving to be defending HN's gold medalist of curmudgeonry twice in one day, but I was going to comment on this anyway:

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

This may be exaggerated, but it has more than a grain of truth. If you take it to mean 90% of programming as actually practiced, as opposed to 90% intrinsically, it's not even that much of an exaggeration.

Working on harder problems in higher-level languages than I used to, I felt less productive for a very long time. In some ways I still do. I eventually figured out that this was because I was spending much more time thinking and much less time typing. Typing feels like good-old-fashioned-work in a way that thinking doesn't. That's why people feel satisfied after cranking out thousands of lines of code, when in reality they may well have made an unmaintainable mess (and thus destroyed value rather than created it).

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.

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.

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.

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.

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.

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

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

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

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

Pair debugging is very productive.

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.

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.

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)

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.

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.

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.

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

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.

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

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

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

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

Totally! These tools are best used in a flexible environment, when you're in need or the situation calls for it. I think it is pretty safe to say that "this way all the time" is wrong for all values of "this way".

Reply on news.ycombinator.com