November 15, 2011

Collaboration and concentration

Latest in the, "People problems are hard, I'm glad I just program computers," set of thought processes. If you have thought-provoking anecdotal data points, your comments are welcome!

There's a confounding and contentious dynamic in programming between collaboration and concentration. This goes beyond just individual and team efficiency — it's also about finding a balance that lets you enjoy and grow your craft.

There are certainly times that you want to hunker down in an LCD-monitor-adorned sensory deprivation chamber and do some badass debugging, find all the corner cases in that nasty algorithm, or suss out all the invariants in a complicated system.

But, on the other hand, there are certainly times that you need to write code during a flurry of peer interaction. If you're ramping up on a new system, the thirty seconds it takes you to ask another human being a question and receive a solid, well-informed answer usually trumps the hours you'd spend reaching the "same" conclusion. With less certainty. Oh, and you actually missed the trap everybody else already knows about, so you actually figured it out wrong.

The extent of the dichotomy is clearly not limited to these examples. It's easy to think of times you've had to pepper somebody with questions as well as times you wanted to hole up in a cave to get some code done. For my systems programming experience I'd hazard a guess that it's around an 80/20 split between concentration and collaboration.

So, it's interesting to ponder: if you were building a team, how would you structure the work space or work activities to enable collaboration when it was necessary, but enable concentration in the common case?

I suppose it's doubly difficult because you also want your team to feel empowered — capable of seeking out collaborative help when they need it in order to get things done and make progress, but also empowered to cordon themselves off and have at it.

I can pretty easily find research that involves hospital workers in the early 1990s, but I have to imagine that a team of brilliant systems programmers is a different beast altogether.