Comment by lowercased

7 years ago

“I don’t know why more people don’t do it,” Sanjay said, of programming with a partner.

=======

Maybe because most employers won't pay for that. Two people? For one level of output? You'd have to prove yourself a level 11 googler before most places would give you the luxury of working as a long-term pair.

Pivotal Labs has had across-the-board pair programming for years[1]. Although the folks there are undoubtedly talented, I'm fairly certain most aren't at Jeff and Sanjay's level.

I don't know why companies don't do it, but it's not cost alone. Here are some of my hypotheses:

1. It seems like it would be more expensive - which might deter companies from thinking about it

2. If you're not already doing it, it's hard to convince all or even a large fraction of your engineers to do it. It's a completely alien way of working to most people

3. It's not obvious to employees who haven't done it that it's clearly better. And it might not be - I honestly don't know

4. For 100% pairing, you need 2 programmers' schedules to line up exactly, 5 days/week - so goodbye flextime, work from home, remote working and all the other arrangements that people structure their lives around

5. It must be exhausting to sit with, and talk to, another person constantly your entire working day

1. https://pivotal.io/careers

  • There've been studies on the "more expensive" part, and IIRC it's about a 15% premium in terms of development time - there've been a few studies. Here's one I could turn up quickly: https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia....

    Simultaneously, you get a bunch of benefits. (Most importantly, there's no bus factor of 1 for anything)

    • Absolutely. Just the bus factor thing was amazing on its own. It's the very rare startup where anybody can take a vacation whenever they need. But that was definitely my experience. Even though I was the first programmer, in pretty short order there was nothing where my absence a blocker. It was great.

    • i'd think another benefit might be 'better code' overall. has there been any study about the quality of code from these setups? number of bugs or security issues, for example?

      1 reply →

  • Regarding #5, you get used to it. It's intense at first, but after a while, it's just normal. One secret is to take actual breaks. And another is to not over-work. When pairing, there's none of that stuff that might stretch out your day. E.g., checking Hacker News. It's solid work time, and after 8 hours of that I'm definitely done for the day.

  • I’ve paired a bit before, and #5 is definitely true. I can only handle 2-3 hours of it.

    • Yeah, based on what I've seen/ heard, pairing should last no more than half the day. It's just too demanding to maintain all day long, like a cognitive sprint.

I don't think that's it. It's typical to have a team of programmers working on a large project, and many managers are willing to try things.

However, pair programming does require a lot of commitment to make it work. I've only seen it work on a team where it was an XP project to start with, so everyone hired was already willing to give it a solid try. Your average team isn't self-selected in this way and won't have the same level of enthusiasm for a new management initiative.

Thats definitely not the only reason. I've been on teams where managers were keen on pair programming but only a couple people ever did it.

I think from the very beginning it was understood they were producing more than one level of output together.