Programmer for Hire

During the course of my programming career, I have found, without exception, the greatest success (be it measured in efficiency, the end result, or even my personal joy in the process) comes with solo projects.

After such a years-long track record it begs a question: am I just another example of the lone wolf coder who either cannot or will not play nicely with the other kids, or is there really something defensible in the idea of a programming team of one?  Central to The Mythical Man Month is the notion that adding people to the programming team of a late project will only make it later, but what about the other extreme?  Can minimizing the headcount to 1 make a better project, and if so, under what conditions?

Communication

Certainly there are some immediate gains that arise.  There’s no redundancy in learning the initial requirements of the project: one point of contact constitutes a massive streamlining of communications, and there is no opportunity for a game of telephone to distort the message as it disperses from client to team.  The same can be said of the nuances that arise during a project’s lifetime: tweaks can be made to a system’s architecture without the penalty of coordinating with other parties impacted by the change.

On a team of one, everyone is always on the same page when it comes to the state of progress and what’s currently on the client’s mind.  An entire class of meetings, the inter-developmental team meeting, can be nixed entirely.

Division of Labor

While out with a few of the guys of the Denver JQuery meetup group last week I heard a lot of people describe themselves as either “front end” or “back end” developers.  This is a useful separation of labor, for the skills of each are reasonably disconnected (front enders are charged mostly with the user interface and making the system look pretty, while back enders are more concerned with the business logic and data shuffling about).  But for most projects the roles are heavily intertwined.  Changes on one side will often necessitate changes for the other, which will take a cycle of communication/waiting/updating/integrating/testing among 2 or more people each time.   For a team of one who is master of both sides of the system, this communication is instantaneous and it’s just a matter of revising the work.

Come to think of it, it’s not just a matter of saving time.  If the logic and flow of a system are handed down from on high as immutable gospel, both parties can work on their parts separately and bring their work to make a near if not perfect fit.  But this is seldom the case.

What really happens is that original designs are either sketches or best guesses: either benefit by evolving from prototypes and earlier drafts.  Lowering the activation energy for tweaks allows it to evolve better simply because it’s less headache to explore new ideas.  When an idea implicates changes that create more work for others, given the choice you’ll more likely stick to the original spec.  If it’s just you and the code, you’ll be far more inclined to take risks.  When you hit a dead end, there’s no one you need to apologize to.

Worthy Collaboration

One piece of teamwork I’ve consistently found to be a great boon to a project is a clear cut relationship between aesthetic design and coding.  A great design for a project makes working on it a joy (bad design kills morale (or at least drains it) and no one is immune), and when I’m given a rich vocabulary of aesthetic elements I can remix and re-purpose them for whatever needs come about.  Thus design in projects is more of a one-time input rather than a you-work-on-your-part-and-I’ll-work-on-mine-and-we’ll-make-sure-they-fit-together-all-along-the-way.

Clearly a team of one needs to be able to many disparate competencies in order to pull off an entire project.  That might suggest that their talent might necessarily be spread thin, but I’m not so sure.  When I am ultimately accountable for a project, there’s much more a sense of pride and ownership for the end result.  You can’t hide behind a story that someone else dropped the ball if the project is less than great.  For those two reasons the entire process becomes the opportunity to really bring your art and have it shine.  Learning an extra trick and going the extra mile is much more enticing because it is much more noticeable and attributable.  Contrast this against the temptation to phone it in and just meet the spec requirements on a project where your part can’t override the overall momentum of the team.

Certainly the team of one is not much of a duplicate-able model for relying on all projects: the larger a project gets, the harder it is to find someone who can be the sole master of it all (let alone be interested in doing so).  But it may be a worthwhile direction in which to grow talent: rather than gauge merit and encourage development along the lines of having increasing years and experience within narrow X, be interested in growing an expanding base of proficiency in X, Y, Z and so on such that the size of a project that could be taken on by one person increases.  The power of a given group of programmers may be best measured as the size of the biggest project that one member of the group could handle alone.