The Art Of Not Writing Code June 2012

Don’t Be A Coder

My friends think of me as a “coder.” I’ve always hated the term, and I finally realized why: I don’t enjoy coding – I enjoy building awesome things. In fact, the only reason I learned how to code in the first place was because I wanted to figure out how to customize one of my video game servers. I initially tried as hard as possible to avoid coding before finally giving in and figuring it out.

That said, code is simply the artistic medium out of which I create beautiful products that streamline people’s lives. It is a means to an end. My true function is not to write code, but to figure out how to build the amazing machines that drive modern-day society. The fact that this involves writing code is coincidental.

Be Lazy… Write Less Code

I’m good at my job because I figure out how to write the minimal amount of code and thus create the maximum amount of value in the shortest span of time. In fact, over the years, I’ve noticed that the more time I invest in researching a problem, the less time it takes to build the solution. For every hour I spend researching, I probably save three hours of writing and debugging code.

See The Big Picture

Implementing these well-researched solutions involves a big-picture, top-down perspective of the problem. There are so many more factors to take into account than just “how do I solve this?” Here is dramatically abridged list of considerations I take into account every day:

How long will this take to implement? How many people will it take? What is the monetary cost of those development hours? Who else will be viewing this code? What are their skill levels? Their needs and motivations? Will they be able to pick up where I left off without needing my help? Is this code written intuitively? What will happen when our business model changes? Will this become obsolete? Will this be secure? What if the wrong person gains access to this system? Is this efficient? Will it affect the performance of the other components of the system? If it fails, will it pull down it’s neighbors like dominos? Is this broken down into modular components that can be maintained and upgraded independently? So “coding” is not so much about writing code, but rather somehow miraculously building a system that somehow satisfies all of these considerations simultaneously. It is very much a process of research, discovery, planning, design, and empathy.


You read correctly: yes, empathy. Coding is a social sport. A huge proportion of thought cycles are spent answering social questions: Who will be working with my code after me? Will it make sense to them? Is it intuitive? Does it require further explanation (hint: good code will rarely require explanation)? How do I avoid conflicts as I work on the same codebase as my peers?

And then there are of course the user-oriented questions: How will the user perceive my software? Is it intuitive? How do I phrase the labels on my UI such that they don’t require further explanation? How can I organize my interface such that the user can efficiently navigate it and manipulate it? Does it get out of their way and let them be productive? Will it become one more program that they’ll need to learn how to use, or will it work intuitively out of the box? (think Apple’s design philosophy vs oldschool Linux GUI’s).

If you’re still reading, I hope I’ve opened your eyes and changed your perception of what “writing code” is all about. It is a talent of foresight, risk, planning, organization, design, careful consideration, research, creativity, and empathy. It is more about “how can I make this problem vanish into thin air?” and less about “how do I write 10,000 lines of code?”.