The George Thorogood of Software Development

Acting as the fiber of Software Construction’s diet, it would seem that good collaboration skills are necessary to produce anything useful.

Indeed, if you go to any tech conference chances are that interspersed between the sessions about actual technology will be sessions devoted to, in some way, collaboration with others. Whether its focusing on getting the most out of SCRUM, or new techniques for Pair Programming, “playing well with others” is a perpetual hot topic.

However, I’ve always regarded the “collaboration” side of software development with a bit of reluctant guilt.

This is largely due to the fact that I’ve actually spent the majority of my programming career as George Thorogood — I [code] alone. (I realize that reading the title of this post, without the introduction could infer another direction, such as “I drink while I code”, which would be be the subject of a much more rambling and incoherent post — if that’s possible).

It’s not that I’ve never worked on teams, can’t work on a team, or actively seek out solo projects. Indeed, I have great memories from projects long past of selfless collaboration, mentorship, and camaraderie.

I have always felt a little embarrassed by my solo status since, while I generally do enjoy working by myself, I tend to project a “solo stigma” onto my situation. Surely anyone who works by themselves will stagnate under the stifling professional isolation, right?

While that’s no doubt a perpetual risk, I don’t think it’s unique to programmers on solo projects. Indeed, being on the “wrong” team or part of a voiceless mass can be severely demotivating and isolating.

Some of the greatest software out there has been authored by individuals working alone. John Carmack of id Software fame has managed to perpetually remain a pioneer of high performance 3D graphics engines — and I image he could have only done it alone.

Clearly he is a genius though, and while it would be disingenuous to say that I didn’t intend a comparison with myself in some way (although drawing a comparison any greater than say, that we both type on keyboards would be spurious since even my best achievement in software engineering would be a mere (unlit) candle to the burning sun that is even the original Castle Wolfenstein 3D), I can admit to the sense of unmitigated control and concentration on something that would be difficult to do in the same way (or at least in the same time frame) with more than one person.

Being able to completely scrap a design, or turn in a completely different direction three times in a morning may seem like sloppy, chaotic software construction, and in some sense it is, but what comes out of the other side tends to be, if nothing else, a unified vision of purpose that all but the most agile teams would have trouble matching.

At the risk of sounding completely solipsistic, I don’t think I’m saying anything new here: pound for pound fewer developers are more productive than more developers, with one developer being theoretically “most productive”. Indeed, the whole reason we have teams of developers at all is because one person can only do so much.

“Not true!”, you protest. “Developers have different specialties. No one can simply “do it all”. I don’t want just anyone messing with my data layer — I need a hibernate guru!”

This sentiment may make sense in theory: put ‘gurus’ in their respective slots, bake at 325 for 2 hours, and watch the quality ooze out. However, in my experience, generalists win out over those that carve out niches for themselves with the reason being simply that most projects don’t require “guru” levels of knowledge.

Admitting that I enjoy, and perhaps even sometimes prefer, to work solo can be interpreted as a sort of professional suicide given that most job interviews eventually get around to asking how well you play with others (or depending on how misguided the interview is, how many people you’ve directly managed).

In fact, the title of the post may conjure up images of a “rebel coder”, a lone wolf, or at the least, someone who’s proud of “going it alone”. So to be clear: I think working on a team can be great. There’s no quicker way to sharpen your tool set if on the right team, and this is especially true early on in one’s career. I merely think that there is no shame in working alone.

In other words, I think that this post is best interpreted as an internal running monologue of one person’s thoughts on working by his lonesome and not a diatribe against working on teams — scatological references in the first sentence notwithstanding.