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.

Moving on

After a little over two years at Floate Design Partners, I have decided that it is time to move on. On March 24, I start at Exari in the role of UI/UX Engineer. This represents a move from client services into product development.

Exari makes document assembly software that allows companies writing similar documents frequently, to streamline the process. The demo for non disclosure agreements on the Exari site will give you a good feel for the software.

Continue reading

Conditional IE classes

The HTML5 Boilerplate popularised the html tag conditional classes pattern. This pattern is usually some variation of:

<!DOCTYPE html>
<!--[if lt IE 7 ]> <html lang="en" class="ie6"> <![endif]-->
<!--[if IE 7 ]> <html lang="en" class="ie7"> <![endif]-->
<!--[if IE 8 ]> <html lang="en" class="ie8"> <![endif]-->
<!--[if IE 9 ]> <html lang="en" class="ie9"> <![endif]-->
<!--[if (gt IE 9)|!(IE)]><!--> <html lang="en"> <!--<![endif]-->
  <meta http-equiv="X-UA-Compatible" content="IE=edge" /> 

Continue reading

Optimising the Typekit Code

The Typekit kit editor provides two versions of the embed code, the default version blocks rendering and the asynchronous version which can produce a flash of unstyled content (FOUC).

In the case of Typekit, I prefer the FOUC over slowing down rendering. The asynchronous code also offers the advantage of your site staying online should Typekit go down.

I decided to spend a little time optimising the asynchronous code Typekit provides. Continue reading

Dear Drupal: Season’s Greetings. Love, Smashing WordPress.

Every day I work with WordPress in one way or another. My Twitter feed is full of WordPress types, and I’m a regular at my local WordPress meetup. I’m a WordPress fan.

The White House hosts a number of Web developers who use Drupal every day. Their Twitter feeds are probably full of Drupal types, and some may well attend the Washington DC Drupal meetup. They are Drupal fans.

Continue reading at Smashing Magazine.