F**k Going Green: Throw Away Your Code

Someone once said there are two types of writers: those that try to get a line perfect before writing the next one, and those who dump everything out fast and revise it later. The latter are often much, much more prolific (or so I hear).

Programmers fall into those categories too. We have natural tendencies to one or the other, but we can definitely encourage ourselves in either direction.

I’m a big fan of the latter camp: get’er done fast, clean’er up later.

I’ve tried both methods. I find that when I try to do things 100% right the first time, I end up wasting lots of time. The second method gets it done a lot faster.

“I think there are two types of writers, the architects and the gardeners. The architects plan everything ahead of time, like an architect building a house…The gardeners dig a hole, drop in a seed and water it…as plant comes up and they water it, they don’t know how many branches it’s going to have, they find out as it grows. And I’m much more a gardener than an architect.”

I don’t know who came up with this quote, but it’s become a mantra for me over the years. I used to obsess over doing things the “right way.” (ADHD people are often prone to both perfectionism AND silly mistakes – ironically.) I found that trying to get every aspect of my work perfect caused me to take far longer to do things than I wanted. And the real reason I did it was to satisfy my own need to get things right – with my job requirements secondary.

The truth is, non-technical people – the people who normally pay our salaries – often appreciate results rather than form. It’s a lot safer to take care of the job requirements first, then your own concerns second.

I’m not telling you to do crappy work, obviously – you’ll get yelled at in code reviews without a doubt. But I encourage you to accept that “good, though imperfect” is far better than “perfect, but unfinished.”

If you love the craft of coding, it’s easy to get attached to something you wrote, or hellbent on doing it “right.” It’s ok. It shows you care about the quality of your work. And maybe you care about the respect of your peers. These are good things.

But there’s a fine line between “caring about doing good work” and “being perfectionistic.” If you spend so much time trying to do something “the right way,” even though other people are telling you it’s good enough – you may be wasting time unnecessarily.

The reason concepts like “pseudocode” and “rapid prototyping” exist is because both coding and product development are hard to get perfect the first time around. Writers create drafts (and often multiple revisions) before they output a finished work. Even good bloggers have editors. So I encourage people to think of your initial batch of a code as a first draft – get it written, then review and clean it up later.

Sometimes you’ll write a fast outline of your code, then at some point realize it was the wrong approach. This is natural. A writing teacher once taught me a great phrase: “I didn’t know what I thought…until I saw what I said.” This ugly first draft is a natural step in the process. Embrace it. Then scrap it and write the better version.

There is a time and a place for each approach.

If you’re working on an experimental product for example – a startup’s MVP, or a demo product your company wants to test out (since they don’t know if people will pay for it) – aiming for “good enough” is often more feasible than “unbreakable.” You don’t even know if your customers care enough to WANT the product yet. Ship that thing as fast as you can and find out.

In another example, let’s say you have a crucial feature that makes a bunch of money for your company, but it’s fairly slow, and needs a snappier rewrite. The stakes are much higher – if this feature isn’t done well, the team will lose that cash. So you’d better think it through, and do some speed testing before you ship it. Launch it to a small subset of users if you can as well – before it goes out to everyone.

I do a mental cost-benefit analysis every time I’m coding or even planning a product. Or if I’m maintaining a public app, I’ll approach each feature this way. If you’re a freelancer, or plan to do anything beyond career coding – management, entrepreneurship, product, etc – I highly recommend practicing this.

What are your thoughts on this? Leave a reply.