Whether you are just hacking up a script, writing the next must-have app, or working for the man, always be writing code as if someone else has to read it and understand it. Usually, that someone else is you, six months into the future, older, wiser, with a different mindset. And you’d hate to piss yourself off then, right?

This hiltmonism is a big one. Its easy to think you can fix something later, even though you know this mysterious later never comes. Its easy to think that you can just get this code out because once its done, its done, even though you know its never done. Its easy to hack to a deadline, and hope you are not the bunny who has to fix it when it fails, even though you are stroking your bunny ears at the time.

You will get to face this code again once in production, with customers and managers screaming. The system is down, the TPS reports are late, and a bunch of suites are pacing behind you making clicking sounds with their teeth. So you open the code, look at it and … cannot make head or tail of it. Code you wrote! Recently! If only you had made it more readable, if only you had used comments, and good variable names, and simple functions and white space and explained any odd algorithms. If only you had made it readable. If you had, you could go “Oh, easy bug”, fix it and be up and running in minutes. Now, you have to reverse engineer it first to figure out what is happening before figuring out what went wrong.

It turns out, my worst code critic is my future self. When coming back to fix bugs or enhance systems, I used to wonder what kind of bonehead would write such bad code, until I remembered that that was me, six months previously. And all the excuses my six month ago self had meant nothing. Deadline? No excuse. Prototype code? No excuse. Copied and pasted from some random website? No excuse.

So all the code I write, and all the code my team writes, we write it for someone else to read. Usually our smarmy judgmental future selves.