4 ms·

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 de

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.
        Huggernaut 5y ago
        > Apparently, pair programming places no value on flow. There are certainly times where flow can be difficult. However I'll offer a few other thoughts. Pairing pairs well with TDD. You write a test, I make it pass, I write a test, you make it pass. This is an extremely easy way to get into flow with a pair which doesn't require much communication beyond the code being written. I often find that the boundary between "flow" and "too deeply invested in current thought process" is pretty blurry. Pairing (and TDD for that matter) allow for an opportunity to _slow down_. Of course, I'm sure there are some masters for whom this is absolutely, totally, a waste of time. For the majority of engineers, I think they can find benefit (though they may find more negatives in other ways). > I just don't see how it's effective I'll give you a list of personal reasons that come to mind for why I find pairing effective (this goes beyond "deliver immediate value"). Of course, that doesn't mean they apply to everyone, or even to a majority, or can't be achieved in other ways: - I am less easily distracted because I am in flow with someone else - I am forced to consider my thoughts more carefully because I need to explain them to someone else - I am confident that someone else can continue this work if I am unavailable - I enjoy the camaraderie and friendships built with my pairs - I quickly learn new tools, tricks and ideas from others - I am able to practice my teaching or coaching skills - I am able to quickly get valuable feedback on ideas as I don't need to bring someone up to speed - I take more breaks throughout the day - I am able to provide and receive significantly more interpersonal feedback due to the high touch nature - I'm likely to discover something I've missed with a different set of eyes - I'm likely to take fewer shortcuts, or to be called up on them - I've become a more effective verbal communicator in the rest of my life Of course, I can also give you a list of reasons why I don't like pairing, to even it out!
    - mgkimsal 5y ago
      interesting analogy. there will, of course, be things the two-player mode can produce because there's more fingers on the piano keys. I can not physically play 15-20 keys with my two hands, but two players easily could. And... it probably sounds 'better' in some regards - richer/fuller/etc. But... it's going to take a lot more practice for people to work that close together physically. There aren't, AFAIK, a lot of piano pieces written specifically for two players - but that may be more a function of my limited knowledge vs something inherent in piano music.
  - MockObject 5y ago
    I suggest you try it for a week. Code as conversation.
    - dkersten 5y ago
      Its important to go in with an open mind and not resist it. If you go in grudgingly thinking its not going to work and you're going to try it only to prove yourself right, then it will of course never work. I'd also read up and see how people do it rather than just having two people sit at a computer but otherwise trying to code like you usually do, otherwise you're unlikely to see any benefits.
      - MockObject 5y ago
        Excellent points. Here are some good ideas for getting started. https://medium.com/@maaret.pyhajarvi/the-driver-navigator-in-strong-style-pairing-2df0ecb4f657 https://medium.com/@maaret.pyhajarvi/the-driver-navigator-in...
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.

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.
        Huggernaut 5y ago
        > Apparently, pair programming places no value on flow. There are certainly times where flow can be difficult. However I'll offer a few other thoughts. Pairing pairs well with TDD. You write a test, I make it pass, I write a test, you make it pass. This is an extremely easy way to get into flow with a pair which doesn't require much communication beyond the code being written. I often find that the boundary between "flow" and "too deeply invested in current thought process" is pretty blurry. Pairing (and TDD for that matter) allow for an opportunity to _slow down_. Of course, I'm sure there are some masters for whom this is absolutely, totally, a waste of time. For the majority of engineers, I think they can find benefit (though they may find more negatives in other ways). > I just don't see how it's effective I'll give you a list of personal reasons that come to mind for why I find pairing effective (this goes beyond "deliver immediate value"). Of course, that doesn't mean they apply to everyone, or even to a majority, or can't be achieved in other ways: - I am less easily distracted because I am in flow with someone else - I am forced to consider my thoughts more carefully because I need to explain them to someone else - I am confident that someone else can continue this work if I am unavailable - I enjoy the camaraderie and friendships built with my pairs - I quickly learn new tools, tricks and ideas from others - I am able to practice my teaching or coaching skills - I am able to quickly get valuable feedback on ideas as I don't need to bring someone up to speed - I take more breaks throughout the day - I am able to provide and receive significantly more interpersonal feedback due to the high touch nature - I'm likely to discover something I've missed with a different set of eyes - I'm likely to take fewer shortcuts, or to be called up on them - I've become a more effective verbal communicator in the rest of my life Of course, I can also give you a list of reasons why I don't like pairing, to even it out!
  - mgkimsal 5y ago
    interesting analogy. there will, of course, be things the two-player mode can produce because there's more fingers on the piano keys. I can not physically play 15-20 keys with my two hands, but two players easily could. And... it probably sounds 'better' in some regards - richer/fuller/etc. But... it's going to take a lot more practice for people to work that close together physically. There aren't, AFAIK, a lot of piano pieces written specifically for two players - but that may be more a function of my limited knowledge vs something inherent in piano music.
- MockObject 5y ago
  I suggest you try it for a week. Code as conversation.
  - dkersten 5y ago
    Its important to go in with an open mind and not resist it. If you go in grudgingly thinking its not going to work and you're going to try it only to prove yourself right, then it will of course never work. I'd also read up and see how people do it rather than just having two people sit at a computer but otherwise trying to code like you usually do, otherwise you're unlikely to see any benefits.
    - MockObject 5y ago
      Excellent points. Here are some good ideas for getting started. https://medium.com/@maaret.pyhajarvi/the-driver-navigator-in-strong-style-pairing-2df0ecb4f657 https://medium.com/@maaret.pyhajarvi/the-driver-navigator-in...

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.