I am a terrible programmer

I recently got this from the co-founder of Artsicle, a startup I interned for over the summer after my freshman year:

From: Scott Carleton

Subject: just refactored your find_art.js that you did over a year ago

Part of me is thinking: in some ways, you were a terrible programmer

Other part is, well shit, it’s worked perfectly for the last 20 months and I’ve never had to touch it. 🙂

Scott is absolutely right: I am a terrible programmer. I don’t comment my code very well. Sometimes I ignore the DRY principle. I tend not to use fancy ternary statements, or worry too much about whitespace. My data structures can get ugly sometimes.

But in other ways, I (dare I say it) am a pretty good programmer. For example, Artsicle is a Rails shop and prior to working for them I had only had very limited experience in Rails or any true MVC framework. After a few weeks, I had mostly picked up the codebase and was building features without inordinate trouble.

I also ship stuff. A lot of stuff. I’ve probably built and released 20 apps over the past two years in a variety of languages and frameworks from Python to Rails to Node to Backbone.

42 Floors even publicly offered me a job to become a programmer for them. You can argue that it may have be undeserved, but either way given my ability to produce products with code, it seems that we have a dilemma on our hands.

Am I a terrible coder, or a good one?

I think it’s clear that we have definitional problem: what makes a good programmer?

In general, my priority since I started coding 10 years ago has been speed. How do I get this built as quickly as possible?

And there’s a very specific reason for that: when you’re working for yourself (and you’re young) it’s very unlikely that any one particular project that you build will be around for very long. So for me, it was more worthwhile to spend less time creating beautiful code so that I could spend more time testing out my minimal products. I always approached programming from a very practical perspective.

For me, the beauty in programming was the fact that it allowed me to build businesses where the only cost was my time.

I always coded with a product in mind; never just for the hell of it.

But when I got to college something interesting happened. Even though I’m a philosophy major, I began to take computer science courses. And approaching programming from a theoretical instead of a practical perspective really opened my eyes. Not only was programming a way for me to build businesses, it also became engrossing as something to study.

Real theoretical computer science (things dealing with complexity theory) actual becomes a lot like philosophy. And what’s funny is that a lot of the supposedly theoretical things that I was learning, actually made me better at building products.

It turns out there are problems that you face every day building an app like Firefly that having a grounding in the principles of computer science can help you with (who’d a thunk it?). If you understand algorithms and data structures you’ll be much better prepared to face a lot of the challenges that crop up building more complex web apps.

So a good coder is someone who has a theoretical understanding of the tenets of computer science, right?

Wrong.

Just because you graduated with a degree in computer science from Penn does not make you the next Jason Cohen or Patrick McKenzie.  You have to do more than just finish your homework to become a good coder.

Like most things in life, the answer to what a good coder is, is somewhere in between the guy who wants to get it out fast and the guy who wants to make it beautiful.

The answer is: a good coder knows when something should be quick and dirty, and when something should be thorough and clean. You learn to ask: is this really necessary? And sometimes taking a extra few hours to plan out how you’re going to build something is necessary. As time goes on that’s certainly becoming true for me.

The stuff I build today is much more likely to used than the stuff I built 5 years ago was. Which means that I have to shift my thinking a little bit. Instead of focusing purely on speed, I’m starting to look for elegance as well (if I didn’t my exasperated co-founders would probably kill me).

So next time you’re working on a project, give some thought to what’s most important: speed or elegance. Learning to answer that question correctly is half the battle.

P.S. In my defense, the find_art.js file that Scott was referencing was supposed to be a prototype. They weren’t sure if people would actually use the feature and wanted to test it. It ended up being so popular that they left it in!

I  write shitty code for my startup called Firefly. If you’re interested in doing better customer support and you have a SaaS business – we can help you.