Rules of Programming

Most of my friends are geeks and quite a few of them are either programmers or system administrators. We all work in our little worlds, perform our little functions and when we get together we pretend that the life outside of our little circle does not exist. Of course we bitch and moan about our jobs but when we do talk about the things we do from 9 to 5 on almost daily bases we rarely discuss the lines of code we have written, the theorems we proved, or the lawsuits we managed to settle out of court. Because of this little peculiarity I know very little about what other programmers write and how they write it – I only know about my style of programming and the styles of people that I work with.

Just like any other process that we perform (including blowing one’s nose or tying one’s shoelaces) programming has a certain set of rules that any programmer must follow in order for his or her program to perform any given task. One of those rules is that you have to decide what you want your program to do before you start writing it.

Today I found out that a principle on which I based my entire 10-year software development experience was wrong. One of the girls in my department was working on a report that involved writing a rather complicated Transact-SQL query. After some time she gave up and asked me for help; when I asked her what she wanted the query to do, she responded that she did not know.

Even though she probably meant it as a joke I began to think about the possibilities of such “unpredictable” programming. If you think about it, most great discoveries of all times were made by accident – if that apple did not fall on Sir Newton’s head we might not have found out about gravity and would still be looking for that sticky stuff that keeps us attached to the ground. Just imagine what we could discover by programming random things into computers just to see what happens! Who knows, maybe we could create artificial intelligence that’s actually really intelligent, or design a model for a hyperspacial time travel device without any relevant research or effort. Just think of all the wonderful possibilities.

Alas, even with such a rule-free approach to programming we would need to come up with some rules – after all if you type in MSGBOX(“HELLO WORLD”) in your Visual Basic program all it will do is respond with a message that would read “HELLO WORLD”. So, in order to come up with the rules I turned to Google – I wanted to see what rules do other programmers use as their guidelines. After a 10-minute search I had compiled the following rules:
1. The first rule of programming: do not program if you have the flu.
2. After three days without programming, life becomes meaningless.
3. When you have learned to snatch the error code from the trap frame, it will be time for you to leave.
And on a more serious note:
4. Have a consistent style.
5. Be easy to read and understand.
6. Be portable to other architectures.
7. Be free of common types of errors.
8. Be maintainable by different programmers.

After much consideration, I decided that my first rule of “rule-free” programming will be the following: “Write code and figure out what it does later.”

You think it’s funny? Well, when I discover and patent a method for traveling through black holes I’ll make sure not to send you a check.