4 ms·

I can't tell if this is sincere or parody [1]. If it's sincere, I think the author is attacking a rather extreme position. Sometimes I like to write code by m

by ggreer 13y ago

I can't tell if this is sincere or parody [1]. If it's sincere, I think the author is attacking a rather extreme position. Sometimes I like to write code by myself. Sometimes I like to pair on stuff. It depends on a lot factors. Is it complicated code? Do I know the language/framework/codebase well? Do I have a peer who knows more than I do about the problem I'm trying to solve? Is it important that multiple people be able to maintain this code? Etc. Like most things, pairing is a trade-off. It can have benefits, but it costs twice as much to write code. That said, I think most people in our industry could benefit from pairing more, not less. Studies on pair programming show significant advantages in many circumstances [2]. If the author is sincere, I hope he'll keep an open mind about an occasional pairing session in the future. 1. http://en.wikipedia.org/wiki/Poe's_law http://en.wikipedia.org/wiki/Poe's_law 2. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101.824&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101...

ghostdiver 13y ago
The problem lies here: > I don’t believe that I’m alone in my opinion. All of my colleagues are very similar. In my 20+ year long career, I’ve only known one person that I suspect would be comfortable with pair programming So I can easily imagine that he was unlucky during his 20+ year career, because it is not easy to find such group of people especially in Age of Everyone Can Become a Programmer.
- JoeAltmaier 13y ago
  Add me to the unusually unlucky then. And all the guys I work with, or ever have worked with. At some point it becomes difficult to dismiss this opinion as 'someone who was unlucky'.
frostmatthew 13y ago
> Studies on pair programming show significant advantages in many circumstances But do these studies take into account employee happiness (and thus potentially losing good developers)? In other words, is it better to have five mediocre engineers pair programming or having five stellar engineers working normally?
- ggreer 13y ago
  From section 6.4, titled "Work enjoyment": All agreed that PP promoted the formation of good team spirit in the beginning of the project. The information radiator and the open workspace were also mentioned as contributors to good team spirit. Two of the developers liked PP more than solo programming and two found no difference. Please at least skim references before calling them into question.
  - frostmatthew 13y ago
    Thank you, FWIW I had read the abstract...I don't normally read (or skim) the entirety of every study somebody cites. But taking your advice I noticed 7.2 contains: All the developers were recruited based on their interest in using agile practices including PP Personally I would prefer not working in a paired programming environment, though I'm not sure it would be a deal-breaker. But I know developers (more introverted than me) who I imagine it might be.
    - ggreer 13y ago
      While it probably biases the numbers a bit, I don't fault the study for picking people who were receptive to new practices. Picking people randomly and forcing them to change practices would just cause resentment. Even though I enjoy pairing, I also doubt I would enjoy working at a place that required people to pair. Rules like that irk me. They're often a symptom of other, bigger problems.
JoeAltmaier 13y ago
If he was insincere, let me assure you that I could make all the same assertions and be entirely sincere. Pair programming is for mediocre programmers who need a lot of support. As a highly productive programmer with decades of successful projects behind me, I can assure you that pair programming would be disastrously disruptive to me; in fact my entire team would bail if it were pushed upon us.
- couchand 13y ago
  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

by ggreer 13y ago

ghostdiver 13y ago

The problem lies here: > I don’t believe that I’m alone in my opinion. All of my colleagues are very similar. In my 20+ year long career, I’ve only known one person that I suspect would be comfortable with pair programming So I can easily imagine that he was unlucky during his 20+ year career, because it is not easy to find such group of people especially in Age of Everyone Can Become a Programmer.

JoeAltmaier 13y ago
Add me to the unusually unlucky then. And all the guys I work with, or ever have worked with. At some point it becomes difficult to dismiss this opinion as 'someone who was unlucky'.

frostmatthew 13y ago

> Studies on pair programming show significant advantages in many circumstances But do these studies take into account employee happiness (and thus potentially losing good developers)? In other words, is it better to have five mediocre engineers pair programming or having five stellar engineers working normally?

ggreer 13y ago
From section 6.4, titled "Work enjoyment": All agreed that PP promoted the formation of good team spirit in the beginning of the project. The information radiator and the open workspace were also mentioned as contributors to good team spirit. Two of the developers liked PP more than solo programming and two found no difference. Please at least skim references before calling them into question.
- frostmatthew 13y ago
  Thank you, FWIW I had read the abstract...I don't normally read (or skim) the entirety of every study somebody cites. But taking your advice I noticed 7.2 contains: All the developers were recruited based on their interest in using agile practices including PP Personally I would prefer not working in a paired programming environment, though I'm not sure it would be a deal-breaker. But I know developers (more introverted than me) who I imagine it might be.
  - ggreer 13y ago
    While it probably biases the numbers a bit, I don't fault the study for picking people who were receptive to new practices. Picking people randomly and forcing them to change practices would just cause resentment. Even though I enjoy pairing, I also doubt I would enjoy working at a place that required people to pair. Rules like that irk me. They're often a symptom of other, bigger problems.

JoeAltmaier 13y ago

If he was insincere, let me assure you that I could make all the same assertions and be entirely sincere. Pair programming is for mediocre programmers who need a lot of support. As a highly productive programmer with decades of successful projects behind me, I can assure you that pair programming would be disastrously disruptive to me; in fact my entire team would bail if it were pushed upon us.

couchand 13y ago
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