Don’t Abuse the License to Suck
Jared Sinclair wrote a blog post on Judicious Use of Shitty Code, which conflates the fact that your old code should look bad:
“Some of the worst code I’ve ever written has been in my most successful projects. Version 1.0 of Pillboxie was a tangle of spaghetti code written without delegation, NSNotificationCenter, or KVO.”
with not needing to hold yourself to standards when working on a project:
“If your goal is only to learn, then write clean code. But if your goal is to build a successful business, then stop trying to impress your heroes. Learn as you go. Be messy.”
To his credit, there is a caveat in the middle to not do things that you know are dangerous or crash prone. The paragraph ends with the question:
“The only question that matters: is this app fun or what?”
This is mixing up three aspects of programming: programming as a discipline, programming as a profession, and programming as a passion. They’re all important, and the reason that you’re programming determines which one is most important.
Programming as a discipline is about learning your craft. It’s spending the time to get to know all of the latest tools. Those tools can be language features, design patterns, API knowledge, or good work habits. Most of these things aren’t horribly fun, but from my own experience holding yourself to solid standards and striving to be a better developer pays off huge dividends as it becomes natural to follow good flows and you develop useful patterns to make it reasonable to hold yourself to high standards.
There is a potential to hit a point where it becomes navel gazing, for instance burning significant amounts of time on trivial style comments in a code review. The thing to do is to catch these when they become truly problematic and find pragmatic workarounds, like instituting automated code formatting as a standard.
Programming as a profession is all about finding a way to turn your code into money. You can sell apps, you can consult, or you can collect a steady paycheck as an employee of a company. If you’re selling apps, the question isn’t “is this code fun?” it’s “is this an app I can build that has the potential to make me money?” Part of being an app you can make is whether it is going to be it being a project that is interesting enough you’ll actually follow through. If it’s truly enjoyable to make that’s a bonus, but it isn’t part of the business side of things.
As you move along to consulting and employment, you don’t get as much freedom to choose what your projects are, but ultimately you get to ask if you’re getting the right mix of monetary and other rewards out of the work, and can always move on to a new consulting job, find a new employer, or switch paths.
The passion for programming is what makes a project fun. It’s what makes it satisfying to solve an esoteric problem, or to write an app that does just the thing that you want. It’s important for keeping the professional part from feeling miserable. Most stories of “how I got into programming” are about a passion for development. It’s what drives developers to want to do great things and push the envelope. It’s an admirable thing to have, but passion without discipline and professionalism is unpredictable and can lead to unreleasable, commercially non-viable, or unmaintainable projects.
The other flaw here is the article talks about “impress your heroes”, but makes no mention of asking your peers for input. When I’m hammering on a problem and can’t find a good solution, I ask my fellow developers for help on the subject. Often another pair of eyes on the problem will point me in the right direction. If that doesn’t yield results, then I add a comment to the code and move on to the next problem. Working in an office full of smart developers has sped up my growth as a programmer more than anything else because it’s now very rare for me to have to accept a bad solution unless I’m taking on a truly ugly problem.
Finally, when I look back at the current code I’m writing years from now (or more likely, about six months from now) I expect to think large portions of it are “shitty code.” If I don’t look back at old code and know how I could have done it better, I’m not growing as a developer. I try to write the best code that I can, but “the best code that I can” is a moving target.