3 ms·

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

by 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.
wccrawford 16y ago
I haven't done much pair programming, but when I've been the co-pilot, I watch what is being written and think about what else needs to be done. If some critical thing gets missed, or I think the code isn't going to do what it's supposed to, I speak up. (That includes syntax, but also logic.) I sometimes (rarely) make suggestions about refactoring or tests that need to be done. I will admit, though, that for a while we jokingly called it 'peer programming' because you were just peering over someone's shoulder. We had a cowboy coder that taught us a LOT of stuff in the short time he was here and 'peer programming' was a large part of that. His time here was disruptive, but I think the whole team is a lot more productive thanks to his short employment. (And his disruptions were mostly him trying to convince everyone to do things a better way.)
kragen 16y ago
Even if that were all that happened, it would still be a more efficient way of avoiding procrastination and sharing knowledge within the team than email and meetings. In my experience, though, the copilot often suggests simpler or less duplicative ways to do things, finds logic bugs rather than just syntax errors, and maintains state in their head that the driver would otherwise have to keep written down. I'm talking about my personal experience here, not how it's supposed to be.

by Udo 16y ago

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.

wccrawford 16y ago

I haven't done much pair programming, but when I've been the co-pilot, I watch what is being written and think about what else needs to be done. If some critical thing gets missed, or I think the code isn't going to do what it's supposed to, I speak up. (That includes syntax, but also logic.) I sometimes (rarely) make suggestions about refactoring or tests that need to be done. I will admit, though, that for a while we jokingly called it 'peer programming' because you were just peering over someone's shoulder. We had a cowboy coder that taught us a LOT of stuff in the short time he was here and 'peer programming' was a large part of that. His time here was disruptive, but I think the whole team is a lot more productive thanks to his short employment. (And his disruptions were mostly him trying to convince everyone to do things a better way.)

kragen 16y ago

Even if that were all that happened, it would still be a more efficient way of avoiding procrastination and sharing knowledge within the team than email and meetings. In my experience, though, the copilot often suggests simpler or less duplicative ways to do things, finds logic bugs rather than just syntax errors, and maintains state in their head that the driver would otherwise have to keep written down. I'm talking about my personal experience here, not how it's supposed to be.