4 ms·

My main argument against pair programming is that you never feel that you have done anything significant. You can never be proud of a single line of code since

by defdac 16y ago

My main argument against pair programming is that you never feel that you have done anything significant. You can never be proud of a single line of code since it's always made by someone else together with you. You can't take credit for an invention/algorithm, and thusly never get the kick of true craftsmanship. You are always expendable and can be shoved around like an animal, especially if you are a true team player that always nods and smile are "the best" to pair up with. In fact, the cowboy programmers still rule the programming session when you pair up with them and they can easily take up most part of the day arguing small uninteristing details until they get it their way making the software theirs - not the team.

gruseom 16y ago
Your second and third paragraphs have nothing to do with pair programming. They indicate crappy management (shoving people around like animals) and a crappy team (nitpicky argumentation) respectively. Your first paragraph is more interesting. How does the fact that someone else also contributed diminish pride in craftsmanship? Presumably it's the program you're proud of, so if the program comes out better, isn't that reason to be prouder? (If the program comes out worse, that's a problem.) Personally, it would drive me crazy to work with people who were constantly worrying about who contributed what. Software development is hard enough as it is. We can't afford to waste valuable cycles on that kind of thing. My experience has been that the solitary-genius fantasy is the calling card of an immature programmer and is purely something to get over. (Just so it's clear, I'm not drawing this conclusion about you, nor about the OP.) It may be true that co-programming makes crappy teams worse, but it also makes great teams better. As far as I'm concerned there's nothing better than a small team of smart people hammering on a hard problem together. But there's no question that it forces team dynamics into the open.
- kayoone 16y ago
  Well since you should change your partner at least once a day, it is about shoving around people ;)
  - gruseom 16y ago
    That's funny, dancers seem to able to do it without shoving each other.
- kunley 16y ago
  Sadly, crappy management is more ubiquitous than cowboy programmers.
  - thibaut_barrere 16y ago
    Funny, I've heard the opposite; from managers, of course :)
    - kunley 16y ago
      As a hacker I'm of course biased, but still I've heard the statement above from a manager in a moment of truth :)
      - mchanson 16y ago
        I think there is plenty of bad programmers and bad managers. I don't think either profession is a lot better than the other. (I am a coder and manager)
        lucisferre 16y ago
        Except that it's easy for just about anyone to spot a bad manager. A manager who doesn't actually know how to code couldn't spot a bad programmer if they fell into them.
- thesz 16y ago
  >It may be true that co-programming makes crappy teams worse, but it also makes great teams better. You missed "may" before "makes" in the second part of your statement.
  - gruseom 16y ago
    That's true. I thought of adding it last night but I was too lazy, and I'm too lazy to fix it now. :)
- yannickt 16y ago
  I prefer solo programming, but to me it means something different from programming without input from other people. I will ask as many questions as I can in order to get the job done. I will describe my design to key team members so it gets criticized and improved. I will ask people to review my code. But when I actually sit down to write code, I don't want anyone looking over my shoulder (with a few exceptions, such as bug hunting or prototyping).
Udo 16y ago
From experience I know only two pair programming roles: the do-er and the yes-man. Which one you are largely depends on the mood of both and the dynamic of the team. So either you're writing code while explaining what you do to your copilot, or you're the copilot who's basically just sitting there, pointing out the occasional syntax error. Now, conventional wisdom says this isn't how it's supposed to be, but I have yet to see a different dynamic in the wild. One thing where I had good experiences regarding paired work was serious bug hunts. There, the most important part was the discussion and the constant back-and-forth of ideas was actually productive.
- dagw 16y ago
  I've also had good experiences in situations where the two parties bring different skills to the table. If, for example, person A really understands the back end algorithm that you're trying to implement and person B really knows the front end codebase you're trying to add that algorithm to. Or if person A really understands the math and person B really knows the programming language. Basically if the two people have more or less well defined roles within the team.
- bajsejohannes 16y ago
  The times I've done pair programming, the co-pilot has been a lot more active than what you describe. While the driver types out the details of a couple of lines, the co-pilot will look at the surrounding code, figure out what to do next, and keep a stack of things to be done (while still keeping an eye on the code being written). Once the driver is done, the co-pilot suggest the next little task. This might lead to a little discussion, which is great, because you have two people who are really into the code. This has been pretty hard algorithmic work, though. No fleshing out hundreds of lines per hour.
  - cscheid 16y ago
    Interesting. The one experience I've had with pair programming was also with non-trivial algorithmic stuff, and we had the same positive experience. I wonder if it's a more general phenomenon: "pair programming is for the hard parts" or something like that.

by defdac 16y ago

gruseom 16y ago

Your second and third paragraphs have nothing to do with pair programming. They indicate crappy management (shoving people around like animals) and a crappy team (nitpicky argumentation) respectively. Your first paragraph is more interesting. How does the fact that someone else also contributed diminish pride in craftsmanship? Presumably it's the program you're proud of, so if the program comes out better, isn't that reason to be prouder? (If the program comes out worse, that's a problem.) Personally, it would drive me crazy to work with people who were constantly worrying about who contributed what. Software development is hard enough as it is. We can't afford to waste valuable cycles on that kind of thing. My experience has been that the solitary-genius fantasy is the calling card of an immature programmer and is purely something to get over. (Just so it's clear, I'm not drawing this conclusion about you, nor about the OP.) It may be true that co-programming makes crappy teams worse, but it also makes great teams better. As far as I'm concerned there's nothing better than a small team of smart people hammering on a hard problem together. But there's no question that it forces team dynamics into the open.

kayoone 16y ago
Well since you should change your partner at least once a day, it is about shoving around people ;)
- gruseom 16y ago
  That's funny, dancers seem to able to do it without shoving each other.
kunley 16y ago
Sadly, crappy management is more ubiquitous than cowboy programmers.
- thibaut_barrere 16y ago
  Funny, I've heard the opposite; from managers, of course :)
  - kunley 16y ago
    As a hacker I'm of course biased, but still I've heard the statement above from a manager in a moment of truth :)
    - mchanson 16y ago
      I think there is plenty of bad programmers and bad managers. I don't think either profession is a lot better than the other. (I am a coder and manager)
      - lucisferre 16y ago
        Except that it's easy for just about anyone to spot a bad manager. A manager who doesn't actually know how to code couldn't spot a bad programmer if they fell into them.
thesz 16y ago
>It may be true that co-programming makes crappy teams worse, but it also makes great teams better. You missed "may" before "makes" in the second part of your statement.
- gruseom 16y ago
  That's true. I thought of adding it last night but I was too lazy, and I'm too lazy to fix it now. :)
yannickt 16y ago
I prefer solo programming, but to me it means something different from programming without input from other people. I will ask as many questions as I can in order to get the job done. I will describe my design to key team members so it gets criticized and improved. I will ask people to review my code. But when I actually sit down to write code, I don't want anyone looking over my shoulder (with a few exceptions, such as bug hunting or prototyping).

Udo 16y ago

From experience I know only two pair programming roles: the do-er and the yes-man. Which one you are largely depends on the mood of both and the dynamic of the team. So either you're writing code while explaining what you do to your copilot, or you're the copilot who's basically just sitting there, pointing out the occasional syntax error. Now, conventional wisdom says this isn't how it's supposed to be, but I have yet to see a different dynamic in the wild. One thing where I had good experiences regarding paired work was serious bug hunts. There, the most important part was the discussion and the constant back-and-forth of ideas was actually productive.

dagw 16y ago
I've also had good experiences in situations where the two parties bring different skills to the table. If, for example, person A really understands the back end algorithm that you're trying to implement and person B really knows the front end codebase you're trying to add that algorithm to. Or if person A really understands the math and person B really knows the programming language. Basically if the two people have more or less well defined roles within the team.
bajsejohannes 16y ago
The times I've done pair programming, the co-pilot has been a lot more active than what you describe. While the driver types out the details of a couple of lines, the co-pilot will look at the surrounding code, figure out what to do next, and keep a stack of things to be done (while still keeping an eye on the code being written). Once the driver is done, the co-pilot suggest the next little task. This might lead to a little discussion, which is great, because you have two people who are really into the code. This has been pretty hard algorithmic work, though. No fleshing out hundreds of lines per hour.
- cscheid 16y ago
  Interesting. The one experience I've had with pair programming was also with non-trivial algorithmic stuff, and we had the same positive experience. I wonder if it's a more general phenomenon: "pair programming is for the hard parts" or something like that.