3 ms·

Actually, it is precisely the experimentation / hunch-following times where I've found the biggest productivity gains -- bouncing ideas around with another smar

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".

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".