5 ms·

I don't agree. I wrote a top-level comment about my (positive) experience pairing, but I'll state it again here because its relevant to your comment: I was on

I don't agree. I wrote a top-level comment about my (positive) experience pairing, but I'll state it again here because its relevant to your comment: I was on a team with one other guy working on a complex distributed-systems project. We were both principle engineers at the company. We delivered the project in under a year and as far as I'm aware from talking with former colleagues, the code is still in production without issue years later. We paired every day for about 11 months. Yes, its mentally exhausting. You need to take regular breaks. You also need buy in from everyone involved, if one person is half-assing it, its going to fall apart. The benefits I saw were many: better quality code (two sets of eyes on the code at all times, two people solving every problem or bug, always someone to ping ideas off), better understanding of the code/knowledge sharing (both of us fully understood every line of code written, why it was like that, what it was for), shipping on time (easier to make decisions to get it production ready quickly when two brains are working on it, easier to avoid bugs, boring tasks like documenting are easier too). I don't think the project could have been completed in the time it was with only two people if we hadn't paired. There was also no disparity in experience or seniority, we were both quite equally matched.

g051051 5y ago
I just can't fathom that. How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours? I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work. Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article.
- MockObject 5y ago
  All those benefits he listed there can, and often do, offset what seems like a waste of an extra programmer.
  - g051051 5y ago
    And my point is that I just can't see it. I collaborate with people, and there's benefit in those relatively short interactions, but I've never seen a situation where it made more sense to pair up like that, unless it's a training scenario.
    - bigmanwalter 5y ago
      It's like arguing if a piano sounds better when played by one or two people at the same time. It's just different. Hard to argue that the solo pianist is "better".
      - g051051 5y ago
        Except in this case, it's like one person playing while another person talks to them about what they're playing. In a purely instructional context, sure. In a performance context, it sounds crazy.
        Huggernaut 5y ago
        In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other. Based on another message above where you said: > No, one person is doing things, and another is watching and talking while the other person is doing things. I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced. In the piano context it's less "I'm going to explain to you what I'm playing right now" and more "What do you think of this chord, does it harmonise well with what you're doing?", "I think maybe changing it to a minor chord would help", "oh, can you show me what you mean?", "yes play the first few notes and I'll do the last one so we can see what it sounds like together". It's a back and forth to progress the whole.
        g051051 5y ago
        > In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other. Apparently, pair programming places no value on flow. > I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced. Yeah, pretty sure I do understand it. I just don't see how it's effective unless the people involved are either both very junior, or it's a training scenario of some kind.
- dkersten 5y ago
  > How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours? This is a very common misconception. Both of you are "working", only one of you is typing. I don't know what kind of work you do, but in my ~20 years of programming, typing is a rather tiny percentage of programming work. Most of it is thinking, problem solving and designing. Both people are doing these things, except you're both doing them on the same task. That means that the task is often done faster, but much more importantly, its done better and the wins really rack up in the long run: you get knowledge sharing for free, you make less mistakes, better designs, write more robust software, better tests (because you have a second person to make sure they're good), have two people working on documentation etc. We ship more complex projects, with fewer errors, better documentation in less time. > I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work. How much of your programming is actually typing into a text editor? Maybe I'm working on different types of code as you, but for me, design/planning and problem solving is takes up about 80% of my "programming time". As I said above, not only is this faster with two brains working on it, but the results are better too. > Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article. Sure. The difference is that you're doing it all the time. Which has the benefits I mentioned above, at the cost of.. its a mentally exhausting way to work. The project I worked on with pair programming was a large complex distributed system to deliver large amounts of data to fleets of airplanes over satellite internet (among other means), with guaranteed delivery SLA's. It took two of us 11 months from start to deployment. I've worked on simpler projects without pair programming that took longer. I don't work there anymore, but last I checked, it was still running in production without problems. I 100% believe that this project would not have been delivered in that time frame by just two people if we hadn't pair programmed.
  - g051051 5y ago
    > I don't know what kind of work you do, but in my ~20 years of programming, typing is a rather tiny percentage of programming work. Most of it is thinking, problem solving and designing. I spend a lot of time typing and thinking. And having to slow down and talk to another human impedes my thinking. It's much faster to just think. > Both people are doing these things, except you're both doing them on the same task. No, one person is doing things, and another is watching and talking while the other person is doing things. > you get knowledge sharing for free It's not free, it takes time to communicate, you're just doing it while trying to complete a task. The disruption to flow seems like it would be a much bigger hit than the marginal gains of trying to teach/knowledge share and work at the same time. > How much of your programming is actually typing into a text editor? The vast majority. It doesn't take me 80% of my time to think and plan. > I 100% believe that this project would not have been delivered in that time frame by just two people if we hadn't pair programmed. I can't comment on that, but I can say that I've never worked on a project that would have benefitted from the kind of pair programming you (and OP) are describing. And it's not that I don't collaborate, but when I do, it's much shorter periods, and much longer stretches of time between. I can spend an hour planning with a peer, and then we go off and do things, and just trust that they work (and we're right the vast majority of time). We have established standards, and code reviews catch edge cases.

g051051 5y ago

I just can't fathom that. How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours? I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work. Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article.

MockObject 5y ago
All those benefits he listed there can, and often do, offset what seems like a waste of an extra programmer.
- g051051 5y ago
  And my point is that I just can't see it. I collaborate with people, and there's benefit in those relatively short interactions, but I've never seen a situation where it made more sense to pair up like that, unless it's a training scenario.
  - bigmanwalter 5y ago
    It's like arguing if a piano sounds better when played by one or two people at the same time. It's just different. Hard to argue that the solo pianist is "better".
    - g051051 5y ago
      Except in this case, it's like one person playing while another person talks to them about what they're playing. In a purely instructional context, sure. In a performance context, it sounds crazy.
      - Huggernaut 5y ago
        In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other. Based on another message above where you said: > No, one person is doing things, and another is watching and talking while the other person is doing things. I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced. In the piano context it's less "I'm going to explain to you what I'm playing right now" and more "What do you think of this chord, does it harmonise well with what you're doing?", "I think maybe changing it to a minor chord would help", "oh, can you show me what you mean?", "yes play the first few notes and I'll do the last one so we can see what it sounds like together". It's a back and forth to progress the whole.
        g051051 5y ago
        > In fluid pairing the driver and navigator are constantly switching roles and bouncing off each other. Apparently, pair programming places no value on flow. > I just don't think you're fully understanding the process, which I'm not surprised (and don't hold it against you) about because it's very nuanced. Yeah, pretty sure I do understand it. I just don't see how it's effective unless the people involved are either both very junior, or it's a training scenario of some kind.
dkersten 5y ago
> How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours? This is a very common misconception. Both of you are "working", only one of you is typing. I don't know what kind of work you do, but in my ~20 years of programming, typing is a rather tiny percentage of programming work. Most of it is thinking, problem solving and designing. Both people are doing these things, except you're both doing them on the same task. That means that the task is often done faster, but much more importantly, its done better and the wins really rack up in the long run: you get knowledge sharing for free, you make less mistakes, better designs, write more robust software, better tests (because you have a second person to make sure they're good), have two people working on documentation etc. We ship more complex projects, with fewer errors, better documentation in less time. > I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work. How much of your programming is actually typing into a text editor? Maybe I'm working on different types of code as you, but for me, design/planning and problem solving is takes up about 80% of my "programming time". As I said above, not only is this faster with two brains working on it, but the results are better too. > Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article. Sure. The difference is that you're doing it all the time. Which has the benefits I mentioned above, at the cost of.. its a mentally exhausting way to work. The project I worked on with pair programming was a large complex distributed system to deliver large amounts of data to fleets of airplanes over satellite internet (among other means), with guaranteed delivery SLA's. It took two of us 11 months from start to deployment. I've worked on simpler projects without pair programming that took longer. I don't work there anymore, but last I checked, it was still running in production without problems. I 100% believe that this project would not have been delivered in that time frame by just two people if we hadn't pair programmed.
- g051051 5y ago
  > I don't know what kind of work you do, but in my ~20 years of programming, typing is a rather tiny percentage of programming work. Most of it is thinking, problem solving and designing. I spend a lot of time typing and thinking. And having to slow down and talk to another human impedes my thinking. It's much faster to just think. > Both people are doing these things, except you're both doing them on the same task. No, one person is doing things, and another is watching and talking while the other person is doing things. > you get knowledge sharing for free It's not free, it takes time to communicate, you're just doing it while trying to complete a task. The disruption to flow seems like it would be a much bigger hit than the marginal gains of trying to teach/knowledge share and work at the same time. > How much of your programming is actually typing into a text editor? The vast majority. It doesn't take me 80% of my time to think and plan. > I 100% believe that this project would not have been delivered in that time frame by just two people if we hadn't pair programmed. I can't comment on that, but I can say that I've never worked on a project that would have benefitted from the kind of pair programming you (and OP) are describing. And it's not that I don't collaborate, but when I do, it's much shorter periods, and much longer stretches of time between. I can spend an hour planning with a peer, and then we go off and do things, and just trust that they work (and we're right the vast majority of time). We have established standards, and code reviews catch edge cases.