No Shitty First Drafts

The shitty first draft workflow has had a very popular presence among writers, which I also adhere to as a blogger. It’s comfortable to begin by taking a scratchpad and jotting down the key facts and ideas without putting any added effort into wording, punctuation, or conciseness. After all, no one else except you is going to see the first draft, so it can serve as a skeleton which, in subsequent drafts, will be fleshed out, crafted, and polished into the final work.

While the same concept may sound compelling in software development, I would strongly advise against it. Bad things are bound to happen if you allow yourself to write sloppy code at any point in time. While it’s good to build early, stripped down versions of your app, you should still hold on to good programming practices. Stripped down only means fewer features—not sloppy and careless programming.

Code is interpreted by a computer. We developers, however, don’t want to interpret code. We want to scan, understand, improve and extend it as efficiently as possible. But a snippet of code I’m writing today may not appear to me the same way six months later. Our programming habits change, we are not going to be in a consistent mindset, and we forget.

I can’t stress enough the importance of being mindful of readability and maintainability. Code should never be treated as sacred or permanent. A computer program is essentially a collection of code blocks that communicate with each another. When one block breaks, it always introduces the possibility of shattering the entire application. That’s why it’s important to make every individual class, method and variable name maintainable in order to facilitate debugging and automated testing.

When collaborating with other developers, you should especially strive to write your code in the cleanest and most easy-to-understand fashion. And the same degree of attention should apply to one-man projects as well. You are your own coworker after all: a bit different each day, and more so on a Monday morning.

If I had to choose between writing performant/optimized code versus clean code, I would have to go with clean code. If your code is clean from the start, it can be easily optimized at a later stage. Messy code will only lengthen that time tenfold.

Even the most experienced and knowledgeable developer can fall victim to laziness and write shitty code simply because he is lazy. Such practices can easily snowball and develop into a vicious cycle where one shitty implementation leads to another, and before long you notice what you’ve cooked up is a pan full of disgusting spaghetti that nobody in the house, including yourself, wants to touch.