I recently attended the Ancient City Ruby Conference in St. Augustine, FL with my fellow Cloudspace engineers Jeremiah, Josh and Michael. Before we all left, our CEO, Todd, tasked us with preparing blog posts and creating training sessions based on what we were about to learn.

Naturally, I kept my ears and mind open during the conference to catch anything that stood out to me. What I took away from the conference is largely esoteric, but I can’t deny that a flash of insight didn’t leave its mark. Maybe reading this will help some other developers that need to hear it…

###Let’s get weird!

One of the earlier talks at the conference was “Let’s Write Some Weird Ruby” by David Copeland. The gist of the presentation was that, through the flexibility of ruby, you can still write applications even if you take away basic operators like nil and logical if branching. I was certainly impressed, not just with Mr. Copeland, but with Ruby as well.

Interestingly enough it wasn’t the presentation itself, but the conversations it spawned, that stuck with me most. That night over dinner with Jeremiah, Josh, and Michael, we discussed the talk a bit further. While listening to Josh and Jeremiah wax philosophical about the merits of functional vs object oriented vs procedural languages, I had a sudden, jarring, moment of clarity: I am not a Computer Scientist… and that’s ok!.

###True wisdom is knowing what you don’t know

I know I’m not a Computer Scientist; I identify more as a problem solver. My best days at the office aren’t proving which practices are best and why, or having the beardiest neck (though sometimes I may); my best days are when I’ve solved something interesting that has eluded other people.

So what does one do with that knowledge? One of our business development guys, Tim, wrote a great post on it.

“There are two kinds of coders: the type who follow best practices and design patterns, TDD-everything, if-it-ain’t-refactored-it-ain’t-right; then there’s the type who make it work, the real ship-or-die folks, the hackers.”

Most of us are a bit of both, but generally lean to one side or the other. There are times when I look at code and think “How can I make this better?”, and there are times I look at code and think “It works, time to move on”.

Identifying where you lie on that spectrum between “I write beautiful code” and “I make s**t work” will help you when you take the time to step back, be honest with yourself, and understand how your own tendencies may be fighting against you. For the “I make s**t work” folks: Yes, everything might appear to work perfectly right now, but is there a feature coming up in the pipeline that’s going to break everything? Do you fully grasp what you just did? Will someone else easily be able to grasp what you just did? Will taking the extra time to turn something into a reuseable gem or concern make someone else’s job easier later?… And the “beautiful code” people, are you falling victim to gold plating? Have you been prematurely optimizing? Does the test suite really need “OVER 9000!?” scenarios? Where’s the line between modular and hard to trace?

Asking yourself these questions can be tough, but in time, and by looking on both sides of the coin, you’ll wind up being a more well-rounded programmer.

You may not be a Computer Scientist… but that’s ok!