Stephen Coyle

Having written a few fairly complex web projects in the last year, I've been learning a tonne of new stuff. Through personal projects like PodStand and Aleastory, and writing CMSs and server components to support my new company's products, I've gone from knowing virtually nothing about web and server programming, to being comfortable with a lot of new things.

One of the feelings I enjoy most, in areas both hobby and professional, is that of looking back over old work and wondering how on earth did I manage this while knowing so little? Sure enough, I recently took stock of the code that used to underpin this site, and had that feeling in abundance. At first, vanity might present feelings of embarrassment or disdain for oneself, but pushing past that allows for a far more constructive outlook: if code you once wrote now looks 'bad' or 'wrong', it means you've improved since writing it.

My college piano teacher passed on a phrase which I've found applies to a lot more situations than piano performance: always forgive yourself during performance, but never forgive yourself during practice. I take it to mean, generally, that letting yourself away with mistakes during practice is just self-deception, and won't help you improve. Instead, you should hold yourself to as high a standard as your skills allow, and work to fix as many mistakes as you can in the time you have. Dwelling on a mistake made during performance only has a negative effect. You can of course make note of these mistakes, and use them to better yourself when practising, but there's no use dwelling on them excessively.

In programming terms, I'd translate the phrase to mean: do your best when making something, but don't beat yourself up if you learn new, 'better' ways you could have done it later.

Doing your best just entails following simple advice like avoiding lazy shortcuts and, if you can, avoiding what you know will cause your future self hassle. It's usually better to have made something at all, even if you were right at the edge of your abilities while doing so, than not having made something at all. Plus, unlike a piano performance, you can always update software to make bugs and problems go away.

Finally, I think the phrase offers a good perspective on others' work. If someone asks for advice, by all means offer it and help them 'practice', but there's no need for unsolicited criticism of someone's 'performance'. I'm not talking about feedback on their creation, but criticism of their actual approach or code. If you think your way of doing something would be 'better', or that they've done something 'dumb', that's fine, but keep it to yourself and offer it when someone wants help.

If you see someone's code and it looks 'terrible', it probably just means they have less experience than you. Likewise, seeing code written by someone with mountains more experience can seem intimidating, but it usually just means they've been doing it longer than you, and you'll get there.¹

In short, I'm pleased to say that this site is now running on shiny new code that I think is pretty good, but I'm looking forward to thinking it's terrible.