Rule #1

Came across this blog from some guy about "signs you're a crappy programmer and don't even know it". It was actually pretty entertaining, in an inflammatory and sarcastic kind of way, whether or not you agree with his opinion on the points. It opens:

You know those crappy programmers who don't know they are crappy? You know, they think they're pretty good, they spout off the same catch phrase rhetoric they've heard some guru say and they know lots of rules about the "correct" way to do things? Yet their own work seems seriously lacking given all the expertise they supposedly have? You don't know any programmers like that?

He then gives a top ten list of indicators, saying you're a crappy programmer if you believe that:

• "Java is all you'll ever need"
• "CPU cycles are a precious commodity"
• "You model all your code in UML before you write it"
• "You think no function should have multiple return points"
• "You apply design patterns to every coding problem"
  

And it goes on. Of course, with any list like this one might agree with some of his opinions, and disagree with others. It's also guaranteed to serve as flame bait. The comments provoked by this dude's blog were more interesting than the actual post.

Of course there is the expected anonymous bashing:

"You create dumb-ass lists of vague assertions & present them as gospel." If -you- code like you blog, God help the recipients of your work.

But what I found interesting is how many of the more, um, "refined" responses echoed what we've long been preaching here as Rule #1: I should be able to read and understand every line of code that you write.

Readability is the key to writing good software. Check out some of the comments:

"I don't care what kind of language you use or how you go about writing it, just as long as I can read and understand your code when I have to maintain it and debug it."

"Your code should be obvious and if not, at least write some comments. Even write comments out before you write the code, and leave them in there if you want to."

"Really, the rules should be considered guidelines, and are good indicators that you need to take another look at your code to make sure it is really what you wanted to do, and that it is readable."

"ALL of us have created code that someone else will think is crappy, the sign of a good programmer is accepting this, but still trying to make it as easy as possible for other programmers - good or not, experienced or not - to understand our code."

This isn't a novel idea, but it's not necessarily one you pick up when you first start slinging code, nor one they really push you on in your CS / programming classes. And it's definitely not something they'll teach you in Industrial Engineering. I first read about it in The Bible many many years ago. (Well no, not that Bible.)

Readability is key. "Clever code" often means that you didn't take the time to think through how to express your design more clearly and simply.

The trick is just to get in the habit of writing code with the Future You in mind. As you all have witnessed, just because a project is over doesn't mean the underlying code gets buried away -- around here, our technologies tend to be reused because problems are often similar. That means someday the Future You is going to have a question about the code, and if You can't read it easily, You will waste a whole lot of time trying to figure out what You should have made clear in the first place. Frankly, this is and should be embarrassing.

There's two kinds of Future You: There's the older, balder, more forgetful You that can't remember why this algorithm was written the way it was, or how it even worked in the first place, and could you possibly have been insane at the time you wrote this code to begin with? Did anyone even look at this monstrosity before you shipped it to the customer?

Or the younger, smarter version of the Future You that we just hired into the office and is now inheriting your old code because you're too busy Managing or whatever it is you do now. This version is simultaneously laughing behind your back at how we used to write applications in the old days, and cursing your name for sticking him/her with a mess of spaghetti code to begin with. How can he/she make the code better if it's impossible to figure out what it was supposed to do in the first place?

So remember Rule #1 -- and if you'll pardon me for sounding like the Old Geezer programmer, which I am -- It's for Your own good.

Oh, and I'll leave you with my favorite line from all 10 pages of comments on that dude's blog:

We're all crappy programmers. There's always a better way to do something.