Clean, Modular Code is Overrated

Published: 1/7/2014

The last company I worked for almost never hired experienced developers, (I was the only experienced hire for years), and instead favored hiring recent college grads with degrees in things like Economics, Philosophy, English, Biology, Physics, and Anthropology. Anything but Computer Science. They hired really smart but completely inexperienced people who had previously expressed no interest in programming. Then they dropped them into a huge, complicated code base for one of the largest Asp.net sites on the web accountable for more than half of the company's revenue. We're talking billions of dollars.

I thought this strategy was nuts. All of these newbies wrote terrible, unmaintainable code.

I spent my first few years at the company in grouchy programmer mode. I railed against messy code and obliterated people during code reviews. I joined the standards committee and helped create reams of documentation for how to write clean, standardized code. I pushed the adoption of Git over our ancient source control system. I whined to my managers about configuration management and integration risk. Every time I was assigned a bug to fix I would rewrite huge swaths of code because it was so bad, I couldn't bring myself to check it in without refactoring everything.

In the meantime, while I was on my quixotic quest to fix all the things, our customers kept telling us how much they loved our website. The company grew, made even more money and became even more profitable. People with no experience in programming were contributing features to the website that had an impact on the bottom line, every week. Even better, some of them were discovering a new passion for programming. (My favorite example of this is the philosophy major that now works at Dropbox).

Faced with mounting evidence against my crusade for better code, I made a few adjustments.

After being a jerk for so many years I wasn't invited to as many code reviews, but when I was, I spent more time talking about the positive aspects of the code. It no longer surprised me to see an explosion of spaghetti code, so instead of complaining about it, I tried to teach them one technique they could use in the future to help them get their job done faster. Code reviews became a teaching opportunity.

When I was assigned a bug, instead of rewriting the code I improved my ability to read other peoples' code. I learned it's best to start with an attitude of respect for the author of the code. Assume they had a plan. Imagine the effort they put into making the feature work, and how proud they were when they finished. Pretend it was written by a younger version of myself. Whatever I had to do to keep a positive attitude while reading the code, because I discovered a positive attitude resulted in me fixing bugs faster. And I made more friends this way.

It turns out, you can build a successful company on top of a giant pile of spaghetti code. In fact, I think this is probably the norm. And railing against hard to read code will result in less friends for you and the code will likely remain the same. So where does that leave us in terms of writing maintainable, readable, beautiful HTML and CSS?

You should write your code to the best of your ability because it shows respect for future maintainers. When you read another person's code, assume they wrote it to the best of their ability and were also trying to respect your time. You'll make more friends this way.

I guess what I'm saying is, clean, maintainable, semantic code is really for the benefit of other developers. 'Do unto others" and all that. So go forth and build websites, and by all means make the HTML semantic and the CSS modular and beautiful, but remember it's not for you. It's not for some obsessive, compulsive desire to get everything perfect and check all the boxes. The extra effort is for your future maintainers. It's for your friends and colleagues.