Collaboration

Have you ever watched little kids at a park? The babies, being babies, barely take notice of one another; after all, they’re new at all this, they’re just figuring out how any of this works. The pre-toddlers, those crawling or just starting to walk, start to interact more. Soon they’re playing with toys on the playground, digging, rolling and such. They play serially. They may be sharing toys, but they more play next to each other than with each other. Only a bit later, as mobility skills and language skills develop, do they start to play in a cooperative way.

As software developers, it often seems that we never get past that “playing next to each other” stage. Sure, we define what the edges of things look like, we discuss design, but we rarely really collaborate on an implementation as it’s actually taking shape, at that moment when so much about architecture and approach is decided. And I would argue that that would be the moment when multiple sets of eyes would produce the greatest direct benefit.

There’s an assumption that there’s a benefit to be had from parallelizing the process — “while I do this, you do that, and she can do this other thing” — and we can move faster. Sometimes that may actually be the case, but primarily when the domain is already well understood, the code is well tuned and well expressed, and the team involved is deeply in synch. We can all point to those moments. They’re always notable. They’re relatively rare.

Real collaboration, working with each other, two, three, four or even more developers in front of a single display, avoids dark alleys, shares knowledge, forces minimization of code (but only down to the point of maximal legibility), forces writing for testability (you are writing tests as you go, aren’t you?) and makes for healthier team dynamics and a healthier code base.