Skip to content

Path to Pretty

by Topper on June 3rd, 2010

I’ve been thinking a lot about my pragmatic approach to programming (sorry to steal from very great books).

I’ve never been the zealot that makes sure all code is perfect before shipping. I also recognize the tremendous value that aesthetic code brings (that’s why I’m a ruby guy). However, the important part of writing code is getting it out to the users. Those users might be your fellow coworkers (if you’re doing something back-endy) or they might be consumers.

My code will not matter unless someone is using it. So I get it out quickly.

That being said, I’ve seen us cut corners too many times and it always comes back to haunt. It costs hours and hours cost dollars. Bad code is not good for anybody.

My users will suffer from bad code because I won’t be able to react to their needs in a timely manner.

I think I have been intuitively following a pattern now for a while that seems to work out. I’ve been calling it “Path to Pretty” in my head.

It’s ok to ship code that I would consider lacking if the intent and next steps for improvement are clear.

By clear I mean that I must be able to go back in 2 months, look at the code and intuitively see what I was trying to do. If it’s not fully optimized or there are 20 extra lines, so be it.

As long as there is a clear path to pretty I now consider my code shippable.

Footnote: I’m sure I’m not the first person to do this and there’s probably some other name for this technique. This article was mostly for my own selfish benefit.

From → Social Web