Programming is an art, not a science. Sure, you can say it is both, but the real value and the real separator between a good programmer and a bad programmer is not about the science. A good computer programmer is an artist, and takes pride in their work because it is well crafted code, not because it is clever or technically advanced or complex.
So what are the characteristics of good code? Well, being bug-free is ideal but is rarely achieved. Reducing bugs is not the main goal of your code, but it is really a side effect of good programming habits. You don’t write code with the express purpose of not introducing bugs, you write code with a goal of solving a problem. After all, what good is a 100% bug-free program that does nothing useful?
If you write code properly, it will be easy to find those pesky bugs. Don’t use the most esoteric and advanced language features, don’t condense your code into as few lines as possible, do use long and meaningful names, and do start with the simple approach. Readability is key here. Nicely crafted code should be easy to read with enough whitespace and comments that even a junior level programmer can follow it. Simple code equates to fewer bugs, and readable code makes bugs easier to find.
If you successfully wrote good code and solved a useful problem, then guess what happens next? You will want to change that code! Yes, the biggest compliment you can receive about an app is “I like that, but I wish it could do this…”. Some people get offended when they receive constructive criticism but that means people are interested enough to care. When you get the polite “that’s nice” comment, that is the kiss of death — that person is not interested, or thinks you are so far away from where you need to be, it’s hopeless.
OK, so you should plan for success, right? Success means changing your code to add new features or improve the app in some way. Now someone will have to read through your code and figure out the best way to make those changes. That someone may very well be yourself, several months into the future, when you may have forgotten the finer details. You will thank yourself for writing clear, readable code, and you will thank yourself for those comments!
What is the main enemy of well written code? You might say ignorance, that some people don’t care about readability, and that is certainly true. However, most of us know deep down inside what we should be doing. The main enemy is time. Deadlines. Being rushed. When we have limited time, readability (comments, for sure) can go out the window. We just try to get the darn thing working and move on to the next rushed project. I have been guilty of this many times, we probably all have once we get to the front lines of shipping products to customers. Customers and managers want everything done yesterday, right?
Do your best to balance the need to finish on time with the need to write clean, readable code. An extra hour today will probably save you three hours in the future. If the definition of success means you will change that code in the future, then try to do it right the first time and make your code readable. Sometimes, if you know there will be a version 1.1 update, you can get 1.0 out the door quickly and then spend part of the 1.1 schedule cleaning up the 1.0 code. There is usually a little more padding in the schedule after the first release. (That’s when the people who were demanding you work overtime to get them the product will tell you “Thanks. Oh by the way, I won’t get a chance to look at that until I get back from my European vacation in three weeks” : )
When you stop trying to be clever with your code, and stop worrying about bytes and milliseconds until you actually have to, that’s when you have turned the corner and are well on your way to becoming a computer programming artist.
Update: After I wrote this post, I read another blog post which says much of what I am saying here about not trying to be too clever. I think it is spot on.