May 2007

Good Programmers?

Just now again, I stumbled across one of these mind-numbing blog posts telling you what makes a "good" - sometimes even "great" - programmer. As always, it went on about programming before college, having programmed in private, knowing all sorts of technologies, being witty and intelligent, etc. etc. etc.. Google it, you'll find dozens of such articles. On those standards I would be a great programmer, as I usually fit almost any point on such ridiculous lists, just as most of us programmers do to a certain extent, and for sure after some time in the programming biz. First of, I do NOT consider myself a "great programmer." Why? Because I have actually worked alongside truly great programmers. Also, I have worked with many a programmer, yet I still do not even need all fingers of one hand to count up all "great ones." So what makes up a great programmer? Actually, you can sum it up to three quintessential points, in increasing degree of difficulty: A good programmer...

  1. ...knows his interface.
  2. ...can communicate his work to anyone.
  3. ...surpasses the time and space constraints of a project.

To make this a bit more clear: (1) pertains to all HCI (human-computer-interface) related stuff like OS, IDE, or keyboard (!); but also libraries, tools, and the knowledge of at least one programming language close to the skill level of writing the API for it. There is no need for somebody knowing several languages, if he can't handle at least one really well. (2) Is about his ability to discuss the needs, problems, requirements, etc. with his boss, a client, or a fellow mate at just the right level of technical detail and conciseness necessary. The third point finally is the most important of all, and usually never even gets mentioned in most of these page-filling "what makes a good programmer"-lists, much to my amusement (and is the main reason why I just had to blog this...). This point implies, a great programmer is capable of telling you how long his job will take (or at least will conclude that he cannot make - for good reasons - a true estimate and will know how to "bet on the safe side"), and he will then finish that job by that estimate. Also, the way he has designed and implemented the program will be such that others can follow as long as they have the technical background ("best practices", etc.), and will have all interfaces and crucial nodes developed in a style which requires minimal and necessary (i.e., optimal) documentation. Of these space and time constraints (deadline, design, implementation, and documentation) all will be fulfilled, and at least one of them will surpass what one was expecting when the project started. I'd say it is usually the toughest aspect making up great programmers.

I know that almost all guys saying they're "good programmers" (just because they're too many) fail at least two of these three requirements, and I freely admit I have my weaknesses in some of them and therefore do not consider myself in the top league (hey, I'm working on it ;)); but at least I realize those are the guys pulling of the great stunts; not the ones who started programming at age ten, do it sixteen hours a day, and know "all" about twenty different IT technologies (believe me, you just can't...). We all are somewhat like this at certain points in time, but the great ones got the above three points right, and especially those three; That's what makes them uniquely different.