2013-05-12 A lifetime of terrible code

Although many entries posted here are far from optimistic, and often glib criticism dressed up in technical jargon, they don’t always come from a position of arrogance. It is not that my code is devoid of mistakes, but understanding the mistakes of others has given me a perspective I wouldn’t be able to achieve in one lifetime of terrible code.

I’m yet to make mistakes worth talking about, but still I feel I should be a little more honest about the terrible code I’ve written.

My earliest adventures with BBC Basic, OPL16 and JavaScript were spent reimplementing primitives. Although I was flushed with pride the first time I derived a sort algorithm, in hindsight I don’t think an exponential runtime was worthy of such hubris.

I then moved on to writing terrible perl, often cgi-bin scripts. It wasn’t until I came back to perl years later that I truly understood why I kept seeing HASH0x1729 in my output. I still wrote code for my amusement rather than clarity, leading to such gems as:

my $spoon=fork();

Later, university drilled Java into me, and I was one of the lucky few not to ward off object orientation with judicious use of static . They did fail to shake out stupid variable names or tricks. I once used an XOR swap to wind up my tutor, and the punishment was explaining it to the rest of the class—he sat astonished as I spent the next hour explaining that one line of code. The moral: Giving me an audience didn’t make me any less of a smart-arse.

As I moved from one language to another, the hardest thing was not to pick up the new ideas but to abandon the old ones. My first Python program had all the hallmarks of a Java refugee. Not decomposing my program into objects but simply wrapping up global variables inside of them. My second python program wasn’t too friendly either.

def color(self): raise Exception("american")

I’ve even had the honour of having my first piece of ruby mocked on twitter. The errant snippet below can be replaced by send() :

response = obj.method(methodname).call(*args)

One of the kinder responses caught me in the act —"That looks like a python programmers first ruby program". No matter how old I get, my code is still embarrassing. Especially the production code i’ve committed (both in the criminal sense and the version control sense).

# ugh task = task.task.task

This particular line was eventually refactored away after being written in haste in a life-or-death moment for a project, and rationalised as artefact of laziness or sleep deprivation. The admission of disgust in the comment may not have explained why the code looked bad, but my coworker knew I already felt bad writing it. I was saved by a public shaming by those three letters.

I don’t imagine this will ever change. The moment I stop being embarrassed by my code is likely the moment I stop learning new ideas. Or perhaps the moment I gain engineering discipline, but that’s a long way off.

The biggest change for me as I’ve grown as a programmer has not been how terrible my code looks, it’s knowing when i’m writing it. At least now I know when I’m up to no good, and can weigh up the tradeoffs between beautiful and working code.