Robert Heaton

Software Engineer /
One-track lover / Down a two-way lane

Take pride or f--- it

27 Mar 2013

The blank, unblemished untitled.txt shimmering in your code editor can mean only one thing. It’s new feature time.

The last feature you built started out beautifully, with sculpted architecture so elegant and exquisite it made you cry a little bit when no one was looking. But things dragged on, and by the end it was all just a bit rubbish. You weren’t particularly proud of any of it and now you’re just happy it’s out of the way. “But everything’s going to be perfect this time!” you tell yourself as you once again eagerly set to work. A bit later you look around and your half-formed feature is already falling apart and on fire. “Well, damn,” you say.

I go through this process with way too many features and projects. I’m sick of it and I know why it happens. I write good code and build good product when I feel proud of what I’m doing. This feeling can come from many sources – a team that values good code, customers who are desperate to get their hands on a feature, or a sense of craftsmanship and a belief that it is just fun to be good. Wherever it comes from, if it’s not there then whatever I’m doing is screwed.

As soon as I lose pride in something, I stop caring about it being good. Its only value to me is as something that I one day won’t have to do anymore. It always starts with the cutting of one small corner, but that’s all it takes. Pandora’s Box is open and the feature is infected. I cut the next corner with only a faint pang of remorse, and after that I don’t even notice the corners anymore.

Because I know that you have to SHIP and that users don’t care what your code looks like and that this feature is REALLY BORING and I just want to get onto the next one. So it doesn’t matter whether my models know about my views or not, because it would take like 20 minutes that WE JUST DON’T HAVE to fix that. I’m breaking protocol, but only in one or two methods, it’s all contained.

But it never ends there. The feature, maybe even the whole product, is tainted. There’s nothing to take professional pride in anymore. There’s no craftsmanship on display. There’s no point making that data parsing module I just wrote readable, because whoever’s reading it sure isn’t going to understand where the data came from. I’ve unleashed the hounds of hell and covered my codebase in bacon.

Losing pride in what you’re doing turns you into a zombie whose only goal other than the ingestion of brains is to finish the feature. By any means necessary. And unless you can get your pride back, this is not going to be pretty. You have to remember what it was like in the before time, in the long long ago. When your controllers were thin and your models weren’t covered in acid and bits of glass. Think hard. Think back.

For my undead redemption I have to either immediately make amends for what I have done or stand up and take a break. Then, with a clear head and a replenished supply of gumption, I have to decide whether to make things right. If I can’t or won’t then this feature is doomed, and I must drive a stake through its heart and move onto something else. Leaving the monster to grow and mutate is not an option.

Too often I feel like spending time doing things right or at least defensively wrong is intellectual self-indulgence. Get it done! Ship it! But bad code slows you down far more than good code does. It’s too easy to write something crap, be forced to write several layers of crap on top of that, shout “LEAN STARTUP” at anyone who questions you and make a shamble for the exit. You need a very good and immediate reason to write bad code, and a vague feeling of pressure or lethargy is not enough.

Because it never ends there. And as soon as the T-virus hits production, you’ve got a code-zombie apocalypse on your hands.

Discussion on Hacker News ➜
Subscribe to my new work on programming, security, and a few other topics. Published a few times a month.
Follow me on Twitter ➜ RSS ➜