A friend of mine used to quote a friend of his, who said, “always behave as if your worst ten lines of code will be written on your tombstone.” I took that advice to heart.
Throughout my career, I’ve always tried to avoid writing bad code. Software is a craft, and quality beats quantity. I want to write the 10 lines of code that can do the same thing as someone else’s 6000 lines – and do it better.
But every time I write “good” code, I find myself looking back over it almost immediately, with some very specific ideas about how I could rewrite it to make it better. In fact, I usually cringe. If only I hadn’t over-engineered this part, or had used composition on that part. Unfortunately, there are deadlines to meet. Once the bad code has been written, it has to be shipped.
All of the code I have ever written, no matter how good it was, turned into bad code as soon as I was done writing it. It almost makes me wonder… should I just write bad code?
And the answer is, “yes.”
Every accomplished author knows that you need to get 10,000 pages of rubbish out of your system before you can get to the good stuff. Similarly, you will never know what good code looks like until you’ve written lots and lots of bad code. The more “bad” code you write, the better your code will get. Other people will eventually start to look at code you’ve written and be impressed. And you will still cringe.
All the code you write in the future will (*should) be better than all the code you’ve written in the past. So write bad code.
What else is there?