I take pride in the work that I do as a web developer. I always try and deliver the best possible work that I can. If you're a developer of any kind whether it's systems, mobile, web or any other type of developer, one of your aims each day should be to deliver the best possible work you can. When we do this we take the time we need within our estimate to deliver the highest quality of code we can afford to.

Quality and time go hand in hand in this case and it doesn't just apply to programming. It applies to everything that we do. If you want to do something right, take the time to do it well.

I come up against this on almost a daily basis with my oldest son. He rushes his homework and then asks me to check it for him. Untidy writing and stupid mistakes in his arithmetic are just two hallmark traits of his rush to finish his homework. At this point I rub out all his homework, even the stuff he got right, and ask him to do again. Before he begins his homework again I tell him that rushed homework is bad homework. If he wants to get it right in the future first time, then he needs to take the time to do it properly. As with all kids he doesn't remember this advice from one day to the next and so he needs to be reminded of it daily. He's getting better and it's good to get him in into the habit of taking his time with his homework now before he starts high school.

A simply example of applying the right amount of quality and time to our work but it's amazing how often I have come up against this in a professional working environment.

I've been in this position a few times where you are expected to deliver a specific piece of work within an allotted time. The time you're given isn't adequate for the amount of work needing done. In the past I would have cut corners. I would have written code without writing tests for it, tested it through the happy path and delivered it for it's intended audience. Bear in mind that while I do this, my line manager at the time is aware of the short cuts taken and is okay with the end result. It's reminiscent of the 'live to fight another day' mantra.

I don't want to fight another day though, and a couple of years ago I remember spending weeks just putting out fire after fire. It was an unpleasant experience made worse by the fact that there was just no room for spending time to deliver quality work. At the time, the company had too much work and little resources to handle everything. So corners were cut and everyone suffered. It's not a nice experience and it's a difficult to recover from this.

I'm more aware now of the need for both quality and time when it comes to delivering your best work. I write tests for my code where I can, I take the time to refactor my code, I test it in a staging environment to check it is working as expected.

When it comes to your work, regardless of the what you do, don't forget that time can have an effect on the quality of your work. It's not a perfect world though and we don't always get the time that we need. We've all been faced with the dilemma of delivering work within a tight amount of time, but rather than letting that be the norm, let that be the exception.