i’ve seen lot’s of different levels of skill out there in developer land (and read others thoughts about them). obviously there is a continuum of human ability and a continuum of problem difficulties. but we are nothing if not pattern making, so i’m making up some groups.
a pre-blather caveat:
most of the software i have written is MIS data storage and retrieval type of systems. basic automated record keeping. the reason I give this caveat is that it takes different kinds of skills to work in different areas. if you write shrink wrapped software, it’s like the major leagues, if you suck you die. quickly.
in the corporate IT world this is not really the case. your company has a core competency that is not IT. if it does that well, it may not need the best IT. i’m not saying we all suck, cause we don’t – i’ve met smart people building enterprise IT (e.g., Martin Fowler is brilliant). remember too that there are many levels of geekitude and areas of knowledge. but all in, you can be just ok at it and still have a job.
not so in shrink wrap or open services markets where the software is the company’s core competency. how many operating systems or search engines do you use?
back to the blather…
i’ve noticed these groups:
- detrimental – these people move you backwards. they mess up good stuff. there aren’t a lot of them, because even in disfunctional organizations they do not last too long. but at least they made Dilbert possible.
- useless – these people have similar skills level as the detrimental people, but they are a bit more honest with themselves and so
they are afraid to break things they didn’t build. they add on their cruft, but don’t actively destroy. often, there can be a good number of these people lying about. - contributors or pluggers – these people will add to the value of a system, but slowly. i have a hard time dealing with this group, because the optimist in me wants to coach them, but in the back of my mind i hear this nagging voice: “that took you 2 weeks! wtf? i could do it in a day, so it should have taken you 2 days”. that fact that i don’t have a day does not cloud my fantasy. these folks are the bread and butter of corporate IT.
- good developers – they do most of the work. not because they work more than the others, although they often do, but because they accomplish more in an hour than the contributors do in a few days. i like to imagine i’m in this class. a successful company could be formed merely by avoiding the above groups and only allowing in good developers (or better).
- heroic – these are the people whose mental model of what’s going on is much closer to reality than the rest of us. this allows them to understand and act much more quickly than merely good programmers can. this level of understanding makes ordinary problems trivial to solve and hard problems possible to solve.
a roomful of monkeys will never write Shakespeare – and a staff of merely good programmers will never build a useful operating system (at least not without a few Brian Kernighan’s or Linus Torvald’s around to write a bunch of the code).
to give an idea of how different these people are, I want to paraphrase Richard Stallman on Linux. by my definition above, Richard is a heroic programmer. he wrote Emacs, won a Macarthur genius award and leads the FSF. he was working on his own OS when Linux came out. i’m pulling from memory, but he said something like: I was surprised how fast Linus wrote the Linux kernel. if you can surprise Richard by programming quickly, you are doing something right!
if you expand from developer to technologists generally, we should all be a lot more thankful of these heroic people (a la Ayn Rand or the Nobel prize). without them we would not have the civilization we do – cars, telephones, computers, CAT scans, radiation therapy, … almost anything that makes our lives different from that of the middle ages was probably invented or at least perfected by a heroic hacker.