Julian Simioni

Drafts are Evil: Write and Be Done

Every 100 days, each of us at 42floors chooses a personal goal to accomplish before the 100 days are up. Back in November, I chose my current goal: write 10 blog posts.

Today is day 100 and this is blog post number 10. There are a lot of things I’ve learned that I could write about, but one in particular stands out to me.

One of the hardest things in the software world is learning to actually ship what you’ve made. It’s much easier to simply continue working: adding new features, fixing bugs, refactoring. Often the work simply isn’t as fun. Building the core of a new product is great: you’re laying the groundwork, making important decisions about the entire architecture of your software. It’s all too easy to put off the finishing touches that are required if your software is actually going to be usable.

It’s even easier to put off the whole idea of finishing all together. Drawing a line in the sand and declaring your software ready for others to use is difficult. It means admitting things aren’t perfect and that you aren’t going to fix them (yet). Worse, it means exposing those flaws for everyone to see.

Writing, as it turns out, is exactly the same. In fact, it’s even more difficult to ship your writing. The inevitable flaws you expose when sharing your words are deeper and more personal than any code. And most writing is much more permanent than software: once shared, it generally doesn’t change very much, except perhaps to fix a few typos1.

So, really, blogging has been the best practice for shipping software I could have chosen. I’ve intentionally tried to embrace imperfection. Every one of my posts needs more work. It would have been easier to sit on 10 drafts, unpublished, for all time. And it really would have been for all time, because none of them will ever be perfect.

My hope then, is that simply by forcing myself to ship lots of imperfect blog posts, my writing will get a lot better. I’ll probably never notice this while I’m writing. Every post I ever work on will have flaws, and whenever I’m writing I’ll be focusing on those flaws.

Every once in a while though, I’ll look back on an old post or two. That’s when I’ll see how far I’ve come.


  1. Which, I believe, is why engineers invented the wiki. It’s much more comfortable to keep something an eternal work in progress.