Bugs suck.

Their entire life span is frustrating. From the initial discovery, to the glaringly obvious fix that you should have applied 2 hours ago.

When working alone bugs become roadblocks that you must either take the time to flatten and remove or navigate your way round. But in the end they have to be dealt with. Of course you can blame your bug on the platform you’re using. Hell, maybe it is Unity’s fault that your game isn’t working, but at the end of the day what does it matter? You still need to find a solution and, unless you’re lucky enough to have the platform you’re working on answering your every bug report, you’re probably going to have to do it alone.

In teams most bugs normally work the same way, you discover them in code you’ve just written and you go and sort them out.

Unfortunately one of the difficult things about coding within teams, is that any code you write isn’t just yours. Sure, you wrote it initially, but chances are someone will add to it, refactor it or just plain change it. This can lead to a few scenarios where bugs can arise and the blame can be subjective. Lets look at a couple of examples:

“Yes, since I added the new functionality to your model, the programme now only works on Wednesdays, but you shouldn’t have written such difficult code to expand!”

This is an extreme example, and in most professional environments not one you’d ever have to deal with, but it’s interesting to look at. Quite obviously this is the fault of the idiot who broke your code, but who cares? It needs to get fixed anyway and although it wasn’t your fault it could be an opportunity to become Mr Reliable and casually refactor all of the mess that the idiot made. Lets look at a better example:

“I found a pre-existing bug in someone else’s code as I was adding to it”

This is always a tricky scenario, and I want to make it clear there is no concrete correct way to handle this problem. Often it can be the case that the pre-existing code may be difficult to understand, maybe it’s a problem with the back end code and you’re a front end developer.

Taking this into account my generalized approach is not necessarily to accept the blame, if it’s not your fault stand by that. But again, does who’s fault it is really matter? It still needs to get fixed.

If you found the bug, you should make it your responsibility.

This doesn’t mean you have to fix it, or spend hours learning Java to refactor your back end code. It does mean that you need to see it through. Don’t just put it down on a ticket and stuff it in the backlog. If there’s any chance you think you could fix it on your own, try it. If you can’t, find someone who can.

The reason I’m even writing this piece is because of what happened to me last week. I found a bug in someone else’s code, I couldn’t fix it properly so I left it. A week later we were in a meeting and some said to me “Hey Luke have you added that fix yet?” and my reply was a very sarcastic and defensive “Have you!?”

I came out of that meeting and realised what an opportunity I’d thrown away. Yes the bug wasn’t my fault and no I couldn’t fix it on my own, but I could have taken charge of it. Although it was just a small bug which in the end had a 2 line fix it had given me the chance to show a room full of my colleagues that I was the sort of developer who would take responsibility for problems within our project, and I ballsed it up.

Bugs are frustrating, but every now and again they can give you a great opportunity to prove yourself, show how dedicated you are to writing good code and that you are happy to take on responsibility when you could so easily pass it to someone else.

Bugs suck, but the person who fixes them doesn’t.