In response to one of Anne’s recent bookmarks — every pro-office (a room, not Microsoft) coders favorite study — Christopher Mahan leave a nice reply about the Super Code Monkey:
No, the 10,000 times more productive developer is the one who has the experience, the guts, the curiosity, the hard-headedness and the stick-to-itiveness to go forth and take over entirely unchartered territories.This developer has carefully selected his tools, mastered his environment, from the idiosyncrasies of his OS, to writing lexical parsers for his language of choice in his language of choice, to tackling problems that to management seem like utter wastes of time but that could resolve a obscure bug on an obscure product, a bug so obscure it has only occurred three times in the History of Computing. Yet, it is in this utter dedication to that task that the brain trains itself to be devastatingly thorough, to anticipate the impact of every single byte on the expected result, to watch in his mind’s eye avenues of opportunities and dead-end boulevards unfold ever-forward, beyond release date, beyond maintenance and product end-of-life, all the way to its ultimate impact on the common psyche of programmers, as tricks of the trade and techniques passed from generation to generation.
In my programming life, my concern has been Everyone Else. While the above is spot on for the guru and the coder with the well developed “mind’s eye,” that still leaves the other 80-90% of the programming world. These are the people who are either not:
- super-brillant by way of base skill or lack of passion and energy to be so
- and/or cannot set the context of their development such that they can shine.
There’s a third category (hinted at by the first), and that’s (usually) older people who’ve realized it’s not that important to worry about it unless you’re running your own company.
In mature software projects, combating all three of those is a constant, difficult, and dangerous task for managers:
- Constant because everyone grows older and looses that youthful passion for coding and Doing the Right Thing.
- Difficult because keeping that youthful passion going to counter to what we consider a “normal” life (in Western society at least).
- Dangerous because you encourage burn-out and risk offending people who want to go home to see their kid.
Ultimately, I’d posit that most software companies are not willing to pay programmers enough money or share in enough profit to sustain the sort of passionate coders you’d “want” and that people like Paul Graham chronicle, fund, and profit from. Good for him and the coders! The Grahamian programmer, as much as I really like the model, is not really the majority programmer, yet most (vocal) code-monkeys, and certainly, the rest of the world, like to think/wish it is.
Passion on the Balance Sheet
Jumping to the end — there’s a lot of hand-waving to insert here — the result for me is that I don’t trust any “normal” philosophy of software development that depends on passion and “youthful energy.” I prefix that with “normal” to exclude people who are Going for the Gold, that is, startups where coders can get insanely rich. The expectation there is that the company is buying your burn-out, so you better work every waking hour for the next 1-2 years to make that money. (Good luck, sucka’s!)
Now, don’t get me too wrong here: I’m not saying that certain endeavors can’t rely on passionate coders, just that not most software projects can’t rely on it whole-sale. As a manager, team, or individual, you have to use that passion as a tool to motivate coders to work and to do good work. But, years of software success and failure have given me a jaundiced view of the expectation that passion and those with mind’s eyes alone will help you deliver the software, if only because there’s so little of that passion out there to hire.
The XP guys had a great gate for this thinking with their 40 hour work week limit. Of all the practices in XP that got ignored — even above the dread paired programming! — that one was immediately jettisoned, and it’s telling of the basic expectations of everyone in the field. I mean, 40 hours isn’t even enough time for all the coffee drinking I do in a week. Come on!
Widen the Focus
Tell me what you have, and that’s when I’ll know if you have anything to start with…
What I’m trying to say more is to step back from the role of the coder, even the development manager, and ask what sort of system and context the company or team working on the project is. How does it work, how much can it be changed, and what can any given actor do with those two levers? Rather than simply saying “you need passionate coders,” what additional methods of getting the code out the door and (if applicable) sold are available? This isn’t to dismiss the role of the programmer at all. Rather, it’s to make sure that all the effort put into the software is used rather than scuttled by the rest of the organization. Put another way: I’ve seen the software efforts of passionate coders wasted when the rest of the organization was not as carefully optimized as the writing of the software. Tragic!