3 ms·

What ... the ... f*? Blindly pushing pair programming is bad enough, but deliberately _trying_ to avoid 'flow' ? That's about the worst idea I've heard from the

by jrabone 15y ago

What ... the ... f*? Blindly pushing pair programming is bad enough, but deliberately _trying_ to avoid 'flow' ? That's about the worst idea I've heard from the cult of mediocrity that is 'Agile'. Pairing on everything is a disruptive waste of both programmers time, unless one programmer is hugely less experienced - in which case, it's not pair programming, it's coaching, and coaching is a different skill set that you can't expect everyone to either WANT to do or to be any good at. Pairing on all design / analysis spikes is just about bearable, and maybe there are benefits to having everyone switch around spikes quickly.

moss 15y ago
Pairing with other experienced programmers works very well for me, and has made me more effective as a programmer. I've also seen our junior developers learn a lot from pairing with each other. In my working environment, with other people who enjoy that style of work, we think it's pretty great. It obviously doesn't work well for you, so I strongly recommend not doing it. Why is it so terrible that people are playing with interesting, creative, sometimes crazy new ideas, and sharing their results?
- jrabone 15y ago
  I have had some good experiences with pairing where I've learned a lot, but more often feel that I've gone for weeks without ever feeling the flow, the point where all the pieces of system come together for me and I can see end-to-end what needs to be written, where and how, and that's what I write code for; if you took that away I'd give up tomorrow and become an accountant. It's more the happy-clappy tone of these articles that grates than the fact the someone's done it and written about it. As someone else pointed out, the experiments are never controlled, never peer-reviewed, and often unreproduceable, but they're always presented as the next great thing to hit software development. It's time to stop with the bullshit, stop with the certified courses, stop with the pretence that if only your team pushed bits of paper around a whiteboard they'll magically become 10 times more productive. Instead, find out how each individual can be the best developer they can be, and facilitate THAT. Of course, that requires investing in actual people management, which is something that is in short supply compared to agile-methodologies-du-jour. However, I've also seen situations where two junior devs have produced some appalling edifice of code between them, so perhaps that's an argument for rotating pairs faster. Personally I feel both they and the company would have better off if they'd been coached by someone with more experience, but that's not pairing, the power relationship isn't equal.
adrianhoward 15y ago
Curiously enough my personal best-ever development experience was with exactly the 90m regular pair switching talked about here where we paired the most/least experienced on particular stories. It was brilliant. Great fun. Energising. Hugely productive. Especially when I was the most experienced person on the pair. I don't understand Arlo Belshee's emphasis on the lack of flow in this setup in his original paper. Personally I've found the combination of good pairing + TDD to be a recipe for getting into flow very quickly. It seems designed to produce those little nuggets of problem/reward that suck you in and keep you grinding away. The practice certainly hasn't worked for everybody (check out Mitch Lacey's try at using it for example http://www.mitchlacey.com/resources/adventures-in-promiscuous-pairing-seeking-beginner%E2%80%99s-mind http://www.mitchlacey.com/resources/adventures-in-promiscuou...) - but having tried it once I would be keen to try it again and try and figure out the contexts that are causing it to work/fail.

by jrabone 15y ago

moss 15y ago

Pairing with other experienced programmers works very well for me, and has made me more effective as a programmer. I've also seen our junior developers learn a lot from pairing with each other. In my working environment, with other people who enjoy that style of work, we think it's pretty great. It obviously doesn't work well for you, so I strongly recommend not doing it. Why is it so terrible that people are playing with interesting, creative, sometimes crazy new ideas, and sharing their results?

jrabone 15y ago
I have had some good experiences with pairing where I've learned a lot, but more often feel that I've gone for weeks without ever feeling the flow, the point where all the pieces of system come together for me and I can see end-to-end what needs to be written, where and how, and that's what I write code for; if you took that away I'd give up tomorrow and become an accountant. It's more the happy-clappy tone of these articles that grates than the fact the someone's done it and written about it. As someone else pointed out, the experiments are never controlled, never peer-reviewed, and often unreproduceable, but they're always presented as the next great thing to hit software development. It's time to stop with the bullshit, stop with the certified courses, stop with the pretence that if only your team pushed bits of paper around a whiteboard they'll magically become 10 times more productive. Instead, find out how each individual can be the best developer they can be, and facilitate THAT. Of course, that requires investing in actual people management, which is something that is in short supply compared to agile-methodologies-du-jour. However, I've also seen situations where two junior devs have produced some appalling edifice of code between them, so perhaps that's an argument for rotating pairs faster. Personally I feel both they and the company would have better off if they'd been coached by someone with more experience, but that's not pairing, the power relationship isn't equal.

adrianhoward 15y ago

Curiously enough my personal best-ever development experience was with exactly the 90m regular pair switching talked about here where we paired the most/least experienced on particular stories. It was brilliant. Great fun. Energising. Hugely productive. Especially when I was the most experienced person on the pair. I don't understand Arlo Belshee's emphasis on the lack of flow in this setup in his original paper. Personally I've found the combination of good pairing + TDD to be a recipe for getting into flow very quickly. It seems designed to produce those little nuggets of problem/reward that suck you in and keep you grinding away. The practice certainly hasn't worked for everybody (check out Mitch Lacey's try at using it for example http://www.mitchlacey.com/resources/adventures-in-promiscuous-pairing-seeking-beginner%E2%80%99s-mind http://www.mitchlacey.com/resources/adventures-in-promiscuou...) - but having tried it once I would be keen to try it again and try and figure out the contexts that are causing it to work/fail.