Life Imitates Code. Essays by Ka Wai CheungEssays by Ka Wai Cheung from around the web.

Coding ● January 2013

Reaching programmer's nirvana

In the last couple of years, I’ve begun the ego-swallowing ascent that all programmers eventually have to take to achieve, what I’ll call, Programmer’s Nirvana.

The trek up the mountain goes something like this. In the beginning, you learn a language, begin coding, and build small things that, at the time, seem monumental. You continue to build and build, learning new tricks of the trade. You eventually figure out why all these big ideas—best practices, patterns, architectures, and frameworks—exist. You eventually see why someone originally built that thing because, five years later, you’re finally presented with the problem whose existence was the sole reason for that thing’s creation.

But, inevitably, no matter how far you think you’ve advanced, the next project comes calling, and some completely new challenge presents itself. Your fifteen years into your career. Shouldn’t you have this stuff down pat by now?

After fifteen years of writing-some-kind-of-code for the Internet, I’ve come to terms with—scratch that—solemnly and contently nod to the fact that no set of patterns or frameworks or toolsets neatly solves every type of problem I’ll encounter. There will be approaches to solve a problem that will inevitably cause a small drip somewhere else in my code. Rarely do I ever feel caught up—that I’ve come across every problem to have the perfect solution, or even the perfect anticipation, for what might be hiding around the corner. And, as soon as I think I have, I soon find out that I haven’t again.

As DHH often writes about, it’s dangerous to get into the habit of thinking you can bat down every business problem by layering abstractions. Over-engineering and premature refactoring are often the patterns in our thought process that get our code all dressed up with nowhere to go.

So, what do I mean by Programmer’s Nirvana? At some point (for me, maybe 12-13 years into my career), you accept this fact. You let go of the romantic idea that your code will be perfect. Aiming for perfect code in a breathing application is like trying to aim at a bullseye from a moving train. And, even if you hit it perfectly, you know there will be a time to aim again.

And, for the lucky ones, at some point after you’ve surrendered, you actually start enjoying making “dirty” coding decisions. Repeat yourself, because right now, it makes sense to write nearly identical code rather than spend time trying to abstract the common bits out. Rip out the ORM and replace it with some nasty, un-Intellisensible raw SQL. Sacrifice elegance for something more crude, because it will make the app run faster, and because the rawness might make things easier to understand for the next developer that gives you a helping hand.

Programmer’s Nirvana is reached when you stop judging your code quality by how pristine it is, and start judging it by why you made those decisions at the time you made them. Once you do that, you can look back on your well-worn application—the one with all the nicks and bruises and weird little imperfections in code but still is running and serving some purpose five years later—with quiet satisfaction rather than discontent.

Originally published Jan 15, 2013 at We Are Mammoth. Go to the next essay in Coding, “Legacy code is good for your company culture”.