What’s it like to write code (and who cares anyway)?

I’ve been writing code for basically as long as I can remember. I started programming on a TRS-80 Model I in 1982, and I haven’t stopped since. Sometimes people ask me how I did that, how I “made” myself learn to program. I didn’t, it was just natural to me. I’ve never really treated programming as anything special, any more important to me than say reading, writing, or cooking. But it is important. It’s what I do to earn a living, it’s what I’ve spent most of my adult life doing. And for the foreseeable future it’s what I’ll continue to do.

Not all programmers are the same. When I was at Microsoft, I worked with some of the greatest programmers in the world. And the thing about that is that you already have to be a pretty good programmer yourself to even appreciate the difference between a so-so programmer and a super-star. It’s so technical, so abstract that even a so-so programmer often can’t tell the difference between good code and great code. There are certain qualitites that make code great, and even though I tend to appreciate them without conscious thought, I’ll try to list them.

succinct — All great code is brief. I’m not saying it’s short, but it’s absolutely no longer than it needs to be. If it needs to be 4 lines long, it is. If it needs to be four pages long, it is (but that happens rarely).
simple — Great code doesn’t require a lot of effort to understand. The logic behind it is explicit. It doesn’t use tricks and shortcuts to make the programmer look clever. You can go back to great code after five years and understand it just as well as you did the day it was written.
repetitive — Very well written code tends to consist of repeated patterns, with small variations. This isn’t to say that it has redundancies or blocks of cut-and-paste search-and-replace code. But similar tasks are done using similar means, which increases the likelihood that the code will work as designed. If it works once, it works every time.
fail-safe — Great code degrades gracefully. When abnormal conditions exist, it fails cleanly. This doesn’t mean that it is cluttered with hundreds of assertions and error tests, but it does mean that variables are always initialized to something safe, conditional statements take possible null values into account, etc.
That’s all I have on great code for now. Maybe I’ll go track down some examples and post them with commentary later.