4 ms·

Pair programming seems to be good, if you have everything defined. But in reality, you research, experiment, hack things around. You work on hunches and quickly

Pair programming seems to be good, if you have everything defined. But in reality, you research, experiment, hack things around. You work on hunches and quickly implement them, then gradually improve them, compare the solutions and find the best. Pair programming would be pointless; rather annoying in this case.

aaronblohowiak 17y ago
Actually, it is precisely the experimentation / hunch-following times where I've found the biggest productivity gains -- bouncing ideas around with another smart and creative person is a lot more stimulating and effective than the code - compile -check loop!
- sandaru1 17y ago
  "code - compile - check" - I'm assuming that you are talking about coding/algorithm bugs. What I'm saying is, lets say you want to find a way to update a web page with live data(http push?). Then you do a brainstorming session with others and get some ideas(comet, bosh, xmpp, etc). If you want to see which technology fits your product most, then it would be a good idea that each person is spending time on different ideas. "brainstorming" is completely different from "coding together", specially coding a hack.
  - aaronblohowiak 17y ago
    for bugs, i find rubber-duck pairing tends to get most of the advantages of pair-programming. for the c-c-c, i was just meaning toying around with new code "ideas". I suppose parallelizing approaches is a good optimization for a certain class of solving strategies, but I was more meaning to imply that your coworkers may have insight into other things (one of my coworkers is all about python, another used to do natural language stuff and i happen to have a degree in psych, so we all bring a different perspective to the same problems, and that is useful.)
- gruseom 17y ago
  It works both ways. Sometimes I want to throw ideas around with a partner and other times I want to go deep inside an intuitive thought process. The key is to recognize what wants to happen at any given moment, and to have a culture that respects that flow. It really bugs me when people try to impose a predefined process on that. But it also bugs me when people come up with reasons to say co-programming isn't productive, when experience shows that it clearly often is. (Not that you were doing either of these things.)
  - aaronblohowiak 17y ago
    Totally! These tools are best used in a flexible environment, when you're in need or the situation calls for it. I think it is pretty safe to say that "this way all the time" is wrong for all values of "this way".

aaronblohowiak 17y ago

Actually, it is precisely the experimentation / hunch-following times where I've found the biggest productivity gains -- bouncing ideas around with another smart and creative person is a lot more stimulating and effective than the code - compile -check loop!

sandaru1 17y ago
"code - compile - check" - I'm assuming that you are talking about coding/algorithm bugs. What I'm saying is, lets say you want to find a way to update a web page with live data(http push?). Then you do a brainstorming session with others and get some ideas(comet, bosh, xmpp, etc). If you want to see which technology fits your product most, then it would be a good idea that each person is spending time on different ideas. "brainstorming" is completely different from "coding together", specially coding a hack.
- aaronblohowiak 17y ago
  for bugs, i find rubber-duck pairing tends to get most of the advantages of pair-programming. for the c-c-c, i was just meaning toying around with new code "ideas". I suppose parallelizing approaches is a good optimization for a certain class of solving strategies, but I was more meaning to imply that your coworkers may have insight into other things (one of my coworkers is all about python, another used to do natural language stuff and i happen to have a degree in psych, so we all bring a different perspective to the same problems, and that is useful.)
gruseom 17y ago
It works both ways. Sometimes I want to throw ideas around with a partner and other times I want to go deep inside an intuitive thought process. The key is to recognize what wants to happen at any given moment, and to have a culture that respects that flow. It really bugs me when people try to impose a predefined process on that. But it also bugs me when people come up with reasons to say co-programming isn't productive, when experience shows that it clearly often is. (Not that you were doing either of these things.)
- aaronblohowiak 17y ago
  Totally! These tools are best used in a flexible environment, when you're in need or the situation calls for it. I think it is pretty safe to say that "this way all the time" is wrong for all values of "this way".