The idea of getting people to help each other rather than pair program is what stood out for me this time, something which Brian Guthrie also pointed out:
“We didn’t do pairing, we did ‘helping’. You can’t get alpha progs to ‘pair’ but they’ll tell you what they know.”
It’s been quite common at the places that I’ve worked at for pair programming to be frowned upon and sometimes that’s not the most important battle to fight so the team will be more selective about its use.
I was discussing this with some colleagues this week and it does seem that pair programming is a trigger word/phrase with negative connotations for productivity.
On the other hand, something which is rarely frowned upon is having a team ‘working collaboratively’ and in fact most of the time this is considered a very good thing.
When we work alone I still find myself calling a colleague over to help me out when I get stuck and while I could probably work something out alone given enough time I don’t think that approach makes sense when working on it with someone else leads to us solving the problem much more quickly.
Josh Bloch speaks along similar lines in the interview with him in Coders at Work:
I don’t like working in total isolation. When I’m writing a program and I come to a tricky design decision, I just have to bounce it off someone else. At every place I’ve worked, I’ve had one or more colleagues I could bounce ideas off of. That’s critically important for me; I need that feedback.
I’ve known people who don’t feel this way – who are willing to program in a vacuum. I think it hurts them.
I think it’s fairly inevitable that if a team is to deliver software effectively then there are going to be times when people are working together to solve problems.
What we choose to call that can be varied depending on the context we find ourself in.