Deciding to be wrong

When writing code, you don’t make a considered decision about every line you write. Much of it is instinct, you’re following your standard practises.

Standard practises are based on past decisions. As technology has improved, these decisions may no longer be valid. Without care, it’s easy to become stuck in a cycle of producing outdated code.

I write this as someone who didn’t write a single line of CSS until 2006.

To avoid stagnation, you need to reconsider your standard practices and the code they produce. This is more than just changing your doctype. Code interacts and you need to reconsider everything at once. For a front end developer: HTML, JavaScript and CSS. If you write any back end code, this needs to change too.

There is no right time to do this, you need to wake up one day and decide everything you know is wrong. Possibly.

Ideally, you could update your skill set between projects and implement the improvements. This doesn’t work, you need to update your skill set on code that will go live. Working on code that won’t go live is nothing more than tinkering.

Working on live code forces you to make the best informed decision you can at the time. Ideas will be tried and discarded, you need to accept at the outset that you’ll reverse decisions only a few months old.

Cringing slightly at code written six months ago is a good thing.

– me

Looking back at a project and deciding you would have done everything exactly the same shows a lack of critical thinking. It’s lacking critical thinking that leads to a stagnation of ideas in the first place.

A good starting point when updating your coding practices is to go back and re-read old articles. Especially those you dismissed out of hand on the first read. You may have missed a better way of coding by instinctively defending your practices.

Listen to industry leaders and people at local meet ups. Neither’s opinion is more or less valid than the other’s, the developer plugging away at a local agency knows just as much as industry thought leaders.

Don’t blindly accept what anyone is saying; what works for them may not work for you. Be open to ideas but not to your own detriment.

As you’re redeveloping your standard practices from the ground up, you can’t work in a vacuum. Have your code reviewed to avoid shortcuts. If you usually work alone – as a freelancer, for example – then offer to swap code reviews with someone in a similar situation.

Having a code review is the only way to guarantee an honest answer to the question “would I let that through a code review?”

A proper review of your standard practices will make your job harder and bring back the enthusiasm. If you do it properly, you’ll be thinking more carefully the code you write.

Having gone through this process recently, I can tell you I’ve never been so sure I am unsure of what I am doing. And I love it.

This post is based on a talk I presented at Web Directions’ WDYK Melbourne.

By Peter Wilson

Peter has worked on the web for twenty years on everything from table based layouts in the 90s to enterprise grade CMS development. Peter’s a big fan of musical theatre and often encourages his industry colleagues to join him for a show or two in New York or in the West End.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.