Today I made a mistake. It was bad. So I asked myself, ‘What Would Rands Do’?

There is a problem.

Words as a developer you do not want to hear. As developers we often get ourselves into the frame-of-mind that we can’t break things. The experience in our past is our guide in how we develop today. I don’t code anything that fails, and nor-should you. Everything that reaches the production server is gold, and is the best code ever written.

But today, five minutes before knocking off there is obviously a problem. Some weakness has slipped into your code, that is why there is a bug. Something small has brought that Gold Code crashing to the ground. That sinking feeling struck as soon as the words drifted across the partition. “A problem? But there can’t be, I don’t code in #Fail.”

Progress is movement in any direction

As a developer you are always learning. Every line of code you push out is another line of code that you learned. Either it was new and something you had to research; it was something you had to pull from the depths of ancient code you remember from long ago; or it was something you know, and are getting faster at. But whatever it is, it is teaching you more about yourself.

As you are always learning, you can always make mistakes. Minimising mistakes is the ultimate goal of every developer, it is our end point, the target we all aim for. The developer who codes with no mistakes is a legend, and also – as far as I am aware – non-existant. That is why the undo key work to infinity, because the guys who coded the software use it as much as we who use the software to make money.

Infallible code is a goal (dare I say Utopia) but it is not real world development. Usually there are issues and constraints stopping your from being awesome (most of them are money), so we do the best we can in the time we have with the thought of coming back to fix it up later.

Fix it later is a Utopian Thought

We never come back. The code sits in progress as we get onto other more pressing projects. And one day it breaks. The boss calls your name, and you know the dark clouds have grown upon the horizon.

Always remember: The size of the bug is not measure on how much you stuffed up. It is measure on how much the client looses. Your boss will assess the bug under that scale; client looses little it is a tiny bug. Client looses a lot then sorry my friend, you are in for the long haul – It may take five minutes to fix, but there will be meetings, code reviews, performance reviews, and scrutiny over the rest of your work.

The money scale is not always accurate, either. The client determines the size of the issue, and we all know how fickle they can be. Your client may have a large account with your company and this is another issue in a long line of them, this bug could terminate the whole relationship. They could be looking at jumping ship to another coding company and so even a small error is a huge hurdle; maybe you are lucky and they are on holidays and you can sneak it through.

Also remember you have probably created a lot of work for your boss too. That is why he is yelling at you.

Houston… You know the rest

So how do we fix this? You will be happy to know, unless the client enjoys issues and problems with their product *cough* you are in for a wild ride. Lets make sure that you can see clearly the issues so that you make the most of this massive fail.

Use a repository. Please

The first thing I do is go back into the repository to find where the problem was. In the back of my mind I am looking for someone else’s name to be on the Commit. ‘Oh, please, let it be Jerry.’ It hardly ever is though, I think once I got lucky.

Finding that commit is like finding cookie crumbs in the thief’s mustache. “It was me. But I don’t break things.” This is where we start to learn what type of Developer you are. Are you going to run, throw it someone else’s face or take it on the chin?

If you are thinking of excuses you may as well pack up and go home. Take up art and craft and knit a beanie. You are not a developer, there maybe excuses, but this one got under the radar and it has your name on it. So own it.

This is the beauty of repository development. It makes you accountable for your bad code. It means that you are to blame. Congratulations. It is now time to own up, wear that uncomfortable blazer of disappointment – and fix the issue.

Fix the Issue

Since it has been some time since you worked on the site you need to dig back through your own code. This is messy, because depending on how old it is, it may prove anger inducing. And yes, you were the ass who developed this, the code is old, messy and prone to breaking – this is not the time to go back and make the code perfect as you had always planned.

Fix the issue and update the site. There will be plenty of time in the review to get disappointed about your code and you may even get to go back and re-factor it. Just fix it and get the hell out; it doesn’t have to be any more painful.

Testing. This is probably where you failed

We are meant to test. Use case tests are important to development. But not matter how hard you try, or how many people you throw at testing a project, things will slip through the cracks. Yes, this is an excuse, but it is also the truth.

Several people may have reviewed the code before it saw the light of the real world, but this one thing got through the cracks. You should always test, and then test again. Hopefully this kind of issue will make you think about how you develop,

Did you miss some form validation? Did you forget to remove some debugging tags? Did your javascript allow code insert, or maybe it buggered up the Analytics? If the issue is big enough it will become part of your Development Procedure.

Start thinking now that something has broken how you will handle this aspect of development next time. It needs to become part of your procedure for it to take effect; write it down in the back of your book. Got a blog? Why not write it there. Twitter, Facebook, anything. Just remember what broke the code last time, and work it out of your procedures.

Anything that has caused problems in the past can cause them again in the future. Do not let those bad practices stick around you you will regret it – no one wants to be fixing the same bugs three years from now.

Every failure is a chance to get better

Do you see it? Nope, not yet.

You don’t really see it yet but there is a silver lining, and strangly enough it is that the problem has happened. You just don’t see it yet through all the yelling and confusion and failure.

This little bug is the honey-to-your-crumpets; that little extra something that will get you closer to your Code Utopia. If you work this properly into your Development Procedures it will make you better. The bigger the issue/bug/problem the more you will learn. So in a strange way, the more the client looses (and in turn your company looses) the better you become.

Remember what makes you a good developer is not how many times you fail – that is the measuring stick of how long you keep a job – what makes you a good developer is how you change your development procedures when a bug is discovered.

So you failed. You caused a problem that many people are angry and hurt by. It could have been an inherent coding problem (ie, you can’t code); it could have been an accident (ie you missed something); it could have been someone else’s problem (ie you’re lying). But in making that mistake you have the opportunity to profit from it the most.