Update (February 2017): There’s now an updated and revised version of this article.
I consider myself a perfectionist.
When I’m writing a program, I want my code to be correct. It has to get the job done. At the same time, I strive to produce code that is perfectly formatted, fast, and (to me) beautiful. That in itself wouldn’t be a problem if all I did was to follow the wisdom of Kent Beck to “first make it work, then make it right, and, finally, make it fast.” Kent is right, of course. His advice is perfectly reasonable. However, and here is the catch, it only works if you know when to stop.
There’s nothing wrong with refactoring and optimizing code per se – in fact, it’s essential to programming. But trying to Make It Right™ at any cost can be dangerous. I know this first hand. After spending countless nights in front of my computer, hacking on open source projects, I know what it’s like to get lost in implementing yet another tweak – a minor change that is supposed to make a difference. I know how it feels like to rewrite the same piece of code over and over again, with no end in sight. It’s frustrating, to say the least.
I don’t strive for the best in everything I do, but writing (prose instead of code) is another creative endeavor where perfectionism has been getting in my way.
The biggest problem I face [with publishing content] is that I’m a perfectionist. I have a hard time writing shitty first drafts and postponing editing until after getting something down on paper first. Instead, I often try to get it “right” the first time, thereby making the writing process unnecessarily painful. The number of blog posts I’ve published this year is evidence enough of my struggle.
I wrote this ten months ago. These days I still suck at drafting. Writing continues to be a painful process most of the time. While I’ve figured out how to publish posts on a regular basis – the secret is to spend more time writing – I’m fully aware of the fact that perfectionism is a formidable obstacle to getting things done.
I like the way Anne Lamott put it in her great book “Bird by Bird”:
Perfectionism is the voice of the oppressor, the enemy of the people. It will keep you cramped and insane your whole life, and it is the main obstacle between you and a shitty first draft.
Perfectionism is a mean, frozen form of idealism
I don’t feel qualified to give you any advice on overcoming perfectionism in writing. As I mentioned earlier, this is something I haven’t puzzled out yet (not sure if I ever will). On the other hand, I do feel comfortable enough to share my thoughts on programming.
Before you open your favorite editor and attempt to achieve an unattainable ideal, consider the following:
Unless you’re building trading systems or similar software where every microsecond counts, you probably don’t need to write the most efficient code ever conceived; not to mention the danger of falling prey to premature optimization. And unless you have a strong reason to believe that your current design is inadequate, chances are that another layer of perfectly crafted abstraction won’t save the day. Moreover, there is no need to thoroughly document every method of your code unless you’re providing an API that is actually used by somebody.
When I work on some piece of code and I feel the urge for perfection creeping in my head, I like to ask myself these questions:
- Does this change really make a difference? Is it worth my time?
- Does it provide value to the users of my software (who don’t care about my code)?
- Does it matter to my coworkers? My boss? My future self?
By all means, I don’t want you to ship crappy code. But I do want you to remember that you have a choice – and more often than not, settling for good enough is a valid choice to make in a tech world that values shipping above all else.
What to do about it
If you’re reading this, you’re probably a programmer yourself. I guess you’re looking for advice that’s a bit more concrete. I get it. Here’re some things that help me overcome perfectionism in programming:
Tooling. Remember that I want my code to be perfectly formatted? For me, tools like gofmt are a godsend. Never do I have to worry about whitespace or other formatting issues again. As a result, I can turn my attention to more exciting tasks.
Pair programming. I’ve experienced that the desire to finish work increases when working in pairs, in particular if you consider the work to be too hard or too boring (or both). Pair programming offers many more benefits; it’s worth giving it a try.
Spikes. Rather than losing myself in details by trying to Make It Right™ from the get-go, I prefer creating a spike first. A spike is a simple (and dirty) end-to-end solution to a given problem; it is meant to be thrown away after exploration.
Deadlines. Having a due date helps me to overcome perfectionism, as long as the date is imposed by someone else (otherwise procrastination takes over). This is the one advice that’s certainly true for both programming and writing.
This piece was inspired by Terrors of perfectionism, a spot-on post on the same subject. Among other things, it helped me realize how often we consider a solution to a problem to be flawed and therefore temporary. Then we end up using it in production until doomsday.
Update (July 26, 2015): Added spikes to the list of helpful strategies.