3 ms·

> 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

> 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.
- jdlshore 5y ago
  I’m not the person you’re responding to, but I find it striking that you’re making very emphatic, very confident statements about things they have experienced and you have not. It’s quite rude. FWIW, I do have experience with pairing, and my experience is the same as theirs: the person not typing does a lot of design thinking. It leaves the person who is typing free to power ahead at full speed, without having to pause for thought.
  - g051051 5y ago
    > I find it striking that you’re making very emphatic, very confident statements about things they have experienced and you have not. You're free to whatever interpretation you wish. I'm glad it worked out for them (and you). > It leaves the person who is typing free to power ahead at full speed, without having to pause for thought. I hope you can look back at that statement and see how ludicrous it sounds.
- dkersten 5y ago
  I think you are deeply misinformed about pair programming and have some ingrained misconceptions. I don't think I can persuade you otherwise though.
  - g051051 5y ago
    I'm just going by what I've seen in my career, as well as the words that you're using to describe the process, what others in this thread are saying (on both sides of the issue), plus the countless articles I've read over the years. The best I can tell you is there is a level of performance where the cost of working in what is essentially an all-day meeting, every day, forever, is far greater than what gains might be obtained by having two people involved to get over whatever issues are better served by being in the pair. It's much, much more effective for me (and most of the people I've ever worked with) to just reach out as-needed for consulting. The only time I do anything like what you're describing is in a learning context, either as teacher or student. In that case, one of us is sacrificing our time to work with the other person, but it is just that, a sacrifice, in order to serve the long term goals of the group.

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.

jdlshore 5y ago
I’m not the person you’re responding to, but I find it striking that you’re making very emphatic, very confident statements about things they have experienced and you have not. It’s quite rude. FWIW, I do have experience with pairing, and my experience is the same as theirs: the person not typing does a lot of design thinking. It leaves the person who is typing free to power ahead at full speed, without having to pause for thought.
- g051051 5y ago
  > I find it striking that you’re making very emphatic, very confident statements about things they have experienced and you have not. You're free to whatever interpretation you wish. I'm glad it worked out for them (and you). > It leaves the person who is typing free to power ahead at full speed, without having to pause for thought. I hope you can look back at that statement and see how ludicrous it sounds.
dkersten 5y ago
I think you are deeply misinformed about pair programming and have some ingrained misconceptions. I don't think I can persuade you otherwise though.
- g051051 5y ago
  I'm just going by what I've seen in my career, as well as the words that you're using to describe the process, what others in this thread are saying (on both sides of the issue), plus the countless articles I've read over the years. The best I can tell you is there is a level of performance where the cost of working in what is essentially an all-day meeting, every day, forever, is far greater than what gains might be obtained by having two people involved to get over whatever issues are better served by being in the pair. It's much, much more effective for me (and most of the people I've ever worked with) to just reach out as-needed for consulting. The only time I do anything like what you're describing is in a learning context, either as teacher or student. In that case, one of us is sacrificing our time to work with the other person, but it is just that, a sacrifice, in order to serve the long term goals of the group.