6 ms·

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 si

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.

dkersten 5y ago
> 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. And yet, my experience has been the exact opposite. > 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. Fair enough. But, have you seriously (as I said in another comment, if you go in expecting it to fail, of course it will fail) tried it?
- g051051 5y ago
  > But, have you seriously (as I said in another comment, if you go in expecting it to fail, of course it will fail) tried it? I don't have to jump out in front of a moving car to know I'll get injured if I do. I've collaborated and worked with others enough to know it's not for me. Others in places I've worked tried it, and it didn't go well, in spite of strong management desire to see it implemented. I'll assert again that I've never seen it actually work, not heard from any of my peers that it worked. And in spite of the comments in the original article touting such benefits as "one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software", that sounds like cognitive dissonance given the horrific problems that it caused.
  - dkersten 5y ago
    > I'll assert again that I've never seen it actually work, not heard from any of my peers that it worked. And I'll assert again that I have experienced it work (in two different jobs, although one was only for a day at a time), seen it work for coworkers and a few of my peers have had it work very well too. Additionally there are other people here in this very comment section asserting that they, too, have experienced it work. For me, it had a very real and positive impact on the projects and was a good personal experience. Your assertions to the contrary won't change that. Your comment reads very like: "So, I have no anecdotal evidence from my immediate peers that it can work so it must not work. You have offered me first hand anecdotal evidence that it can, I shall ignore that." At this point, I have to wonder why you're even in this comment thread, since you seem so completely stuck and rigid in your beliefs. I'm not saying you have to try it, just don't knock it if you haven't. I'm also not even saying that it will work for you. Maybe it really won't. But you're here adamantly proclaiming that it doesn't work and is a waste of time as if its some immutable truth when it really isn't, evidenced by the fact that it has worked for me and others. Also, your car analogy is invalid. Its not at all like that. That's a bit like saying that you don't need to fly in an airplane to know they can't fly because you know other similarly heavy objects like rocks can't fly. That is, just because you know what would happen when being hit by a car without actually being hit by a car can't be applied to this very different situation.
    - g051051 5y ago
      > Your comment reads very like: "So, I have no anecdotal evidence from my immediate peers that it can work so it must not work. You have offered me first hand anecdotal evidence that it can, I shall ignore that." No, it's "I have strong first hand evidence from seeing the attempts at my and other work places that pair programming is not a slam dunk improvement for software development". > At this point, I have to wonder why you're even in this comment thread, since you seem so completely stuck and rigid in your beliefs. Back at you. I'm not the only one here with strong misgivings and counter examples. > But you're here adamantly proclaiming that it doesn't work and is a waste of time as if its some immutable truth when it really isn't, evidenced by the fact that it has worked for me and others. I stated that I don't care how others get their work done. You want to pair program? If you can maintain or exceed the expected productivity of the rest of the team, then you do you. What I strenuously object to is the heavy handed application of this "concept". > Also, your car analogy is invalid. Yours isn't much better. Rocks can certainly fly, if you provide enough force, but they don't do it easily and they don't do it well, and require a huge effort to make it happen. I wouldn't want to travel by flying rock.

dkersten 5y ago

> 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. And yet, my experience has been the exact opposite. > 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. Fair enough. But, have you seriously (as I said in another comment, if you go in expecting it to fail, of course it will fail) tried it?

g051051 5y ago
> But, have you seriously (as I said in another comment, if you go in expecting it to fail, of course it will fail) tried it? I don't have to jump out in front of a moving car to know I'll get injured if I do. I've collaborated and worked with others enough to know it's not for me. Others in places I've worked tried it, and it didn't go well, in spite of strong management desire to see it implemented. I'll assert again that I've never seen it actually work, not heard from any of my peers that it worked. And in spite of the comments in the original article touting such benefits as "one of the best things I’ve ever done for myself, socially and emotionally, and it produced some great software", that sounds like cognitive dissonance given the horrific problems that it caused.
- dkersten 5y ago
  > I'll assert again that I've never seen it actually work, not heard from any of my peers that it worked. And I'll assert again that I have experienced it work (in two different jobs, although one was only for a day at a time), seen it work for coworkers and a few of my peers have had it work very well too. Additionally there are other people here in this very comment section asserting that they, too, have experienced it work. For me, it had a very real and positive impact on the projects and was a good personal experience. Your assertions to the contrary won't change that. Your comment reads very like: "So, I have no anecdotal evidence from my immediate peers that it can work so it must not work. You have offered me first hand anecdotal evidence that it can, I shall ignore that." At this point, I have to wonder why you're even in this comment thread, since you seem so completely stuck and rigid in your beliefs. I'm not saying you have to try it, just don't knock it if you haven't. I'm also not even saying that it will work for you. Maybe it really won't. But you're here adamantly proclaiming that it doesn't work and is a waste of time as if its some immutable truth when it really isn't, evidenced by the fact that it has worked for me and others. Also, your car analogy is invalid. Its not at all like that. That's a bit like saying that you don't need to fly in an airplane to know they can't fly because you know other similarly heavy objects like rocks can't fly. That is, just because you know what would happen when being hit by a car without actually being hit by a car can't be applied to this very different situation.
  - g051051 5y ago
    > Your comment reads very like: "So, I have no anecdotal evidence from my immediate peers that it can work so it must not work. You have offered me first hand anecdotal evidence that it can, I shall ignore that." No, it's "I have strong first hand evidence from seeing the attempts at my and other work places that pair programming is not a slam dunk improvement for software development". > At this point, I have to wonder why you're even in this comment thread, since you seem so completely stuck and rigid in your beliefs. Back at you. I'm not the only one here with strong misgivings and counter examples. > But you're here adamantly proclaiming that it doesn't work and is a waste of time as if its some immutable truth when it really isn't, evidenced by the fact that it has worked for me and others. I stated that I don't care how others get their work done. You want to pair program? If you can maintain or exceed the expected productivity of the rest of the team, then you do you. What I strenuously object to is the heavy handed application of this "concept". > Also, your car analogy is invalid. Yours isn't much better. Rocks can certainly fly, if you provide enough force, but they don't do it easily and they don't do it well, and require a huge effort to make it happen. I wouldn't want to travel by flying rock.