3 ms·

Sure, you wouldn't respond well if it was forced on you. But what if you tried it sincerely? What if your whole team said, "this week we're going to try an ex

Sure, you wouldn't respond well if it was forced on you. But what if you tried it sincerely? What if your whole team said, "this week we're going to try an experiment." Don't nitpick or naysay, just try it and see. Your use of the word "would" is very telling that you haven't tried.

JoeAltmaier 13y ago
Its funny; imagining the folks oppose PP because they've never tried it. Like we've been in some sort of cocoon or glass jar all our lives. Sure, I've had to endure somebody trying to 'help' when I have a hard problem to find. I spend my time explaining to the other guy, bringing them up to speed. And they spend their time suggesting things that have already been done, or suggesting using some buzzword toolchain like it will solve all the problems. If I were churning out web logic or designing dialogs or some such it can be useful I suppose - "You forgot a brace. Remember we have to try all these on the proto server first." etc. But I spend my time on tricky problems in the core IP of our company. I've always had that job, wherever I work. And let me tell you, having someone in the same room is a no-go for the hours of mental model-building it takes to diagnose or design these kind components. Now, let admit there are different kinds of programming jobs. Maybe the bulk of web design etc is amenable to having two shovels in the same ditch - of course you'd get more done, its obvious! But for other tasks it is absolutely not going to help.
- ggreer 13y ago
  Ouch. It sounds like the skill and/or knowledge discrepancy was too great. I've been in that situation before. If it doesn't get better after about 30 minutes, I say something like, "I don't think this is working out. Let's split up." If possible, I try to suggest something else to work on separately. When it comes to code complexity, meta-studies argue against your claim. Pairing isn't worthwhile for simple code, but it's great for reducing defects in complex code: The benefit of pairing is greatest on tasks that the programmers do not fully understand before they begin: that is, challenging tasks that call for creativity and sophistication.[1] I and most everyone I've paired with have found this to be the case in our own work. A side note: I'm not sure what your core argument is. Most of your comments in this thread seem to be a combination of self-aggrandizement, personal opinion, and veiled insults towards those who pair. I've tried to keep my own comments civil and evidence-based, but many others in this thread are full of negativity. It makes me sad. 1. http://en.wikipedia.org/wiki/Pair_programming#Meta-analyses http://en.wikipedia.org/wiki/Pair_programming#Meta-analyses
  - JoeAltmaier 13y ago
    Sorry if I'm being insulting. I get that way when responding in kind. There does seem to be more emotion than logic expressed here. I've meant to try to counter this with sincere expressions of my experiences. I must have gotten emotional in return. I'm at my wits end, trying to counter the simplistic claims of PP proponents that everyone else is a cowboy or just too inexperienced to 'get it'. I get it, I don't like it, I can see constant refutation of the whole idea of PP in my team.
  - JoeAltmaier 13y ago
    Btw did you mean to use that link to support PP? It says things like "reduce development time somewhat and produces marginal positive effects on code quality"
  - memracom 13y ago
    That sure sounds like a piece of work where a design discussion is necessary. However, I would not call a design discussion, pair programming. Find one or two others to help you hash out a design, but once you understand the problem, there is no need to pair program. Just build it, and call on the same people to do code review after you have built it. A good professional engineering environment where you start a sprint by having a design discussion with peers, and then come back to your peers on the tail end of the sprint for code review, is likely to provide all the same benefits as pair programming. After all, this is not supposed to be a software factory. Developing software is engineering work, and designing the work well, with your peers, will do just as much to strengthen the team and it will also improve the work quality. Working in pairs is useful in bringing junior people up to the next level, and in helping newcomers learn the problem domain or the platform/framework that you use, but it is not a universal good practice that you would use all the time.

JoeAltmaier 13y ago

Its funny; imagining the folks oppose PP because they've never tried it. Like we've been in some sort of cocoon or glass jar all our lives. Sure, I've had to endure somebody trying to 'help' when I have a hard problem to find. I spend my time explaining to the other guy, bringing them up to speed. And they spend their time suggesting things that have already been done, or suggesting using some buzzword toolchain like it will solve all the problems. If I were churning out web logic or designing dialogs or some such it can be useful I suppose - "You forgot a brace. Remember we have to try all these on the proto server first." etc. But I spend my time on tricky problems in the core IP of our company. I've always had that job, wherever I work. And let me tell you, having someone in the same room is a no-go for the hours of mental model-building it takes to diagnose or design these kind components. Now, let admit there are different kinds of programming jobs. Maybe the bulk of web design etc is amenable to having two shovels in the same ditch - of course you'd get more done, its obvious! But for other tasks it is absolutely not going to help.

ggreer 13y ago
Ouch. It sounds like the skill and/or knowledge discrepancy was too great. I've been in that situation before. If it doesn't get better after about 30 minutes, I say something like, "I don't think this is working out. Let's split up." If possible, I try to suggest something else to work on separately. When it comes to code complexity, meta-studies argue against your claim. Pairing isn't worthwhile for simple code, but it's great for reducing defects in complex code: The benefit of pairing is greatest on tasks that the programmers do not fully understand before they begin: that is, challenging tasks that call for creativity and sophistication.[1] I and most everyone I've paired with have found this to be the case in our own work. A side note: I'm not sure what your core argument is. Most of your comments in this thread seem to be a combination of self-aggrandizement, personal opinion, and veiled insults towards those who pair. I've tried to keep my own comments civil and evidence-based, but many others in this thread are full of negativity. It makes me sad. 1. http://en.wikipedia.org/wiki/Pair_programming#Meta-analyses http://en.wikipedia.org/wiki/Pair_programming#Meta-analyses
- JoeAltmaier 13y ago
  Sorry if I'm being insulting. I get that way when responding in kind. There does seem to be more emotion than logic expressed here. I've meant to try to counter this with sincere expressions of my experiences. I must have gotten emotional in return. I'm at my wits end, trying to counter the simplistic claims of PP proponents that everyone else is a cowboy or just too inexperienced to 'get it'. I get it, I don't like it, I can see constant refutation of the whole idea of PP in my team.
- JoeAltmaier 13y ago
  Btw did you mean to use that link to support PP? It says things like "reduce development time somewhat and produces marginal positive effects on code quality"
- memracom 13y ago
  That sure sounds like a piece of work where a design discussion is necessary. However, I would not call a design discussion, pair programming. Find one or two others to help you hash out a design, but once you understand the problem, there is no need to pair program. Just build it, and call on the same people to do code review after you have built it. A good professional engineering environment where you start a sprint by having a design discussion with peers, and then come back to your peers on the tail end of the sprint for code review, is likely to provide all the same benefits as pair programming. After all, this is not supposed to be a software factory. Developing software is engineering work, and designing the work well, with your peers, will do just as much to strengthen the team and it will also improve the work quality. Working in pairs is useful in bringing junior people up to the next level, and in helping newcomers learn the problem domain or the platform/framework that you use, but it is not a universal good practice that you would use all the time.