Development Endeavours

I thought when I grew up the whole blame game would be done. But, I guess not since it’s something that I hear way too often in the workplace. Mistakes happen, and changes get made in code that we write every day, but I still fail to see the value in finding someone to pin the target on.

At a high level (at least in my eyes), it’s a defence mechanism. “If something bad happens and it’s not linked with me then that means I’m safe”. Sure, I guess that is correct to an extent, but it’s also missing the whole point of being a team. We win as a team, and we lose as a team. There are a few reasons why software development is a team sport, I’ll list a few:

• We can collaborate on the design of the code, two heads are better than one.
• If people are stuck, sometimes it helps to talk it out with others.
• Other people may have tried a similar thing in the past that didn’t work, they can explain why.

By the very nature of how lots of organizations set up their repositories, you typically need at least 2 other people to review your code and say it’s good in order for it to be merged. If the people doing that review were doing their job, then how is it even possible we start the blame game and point a finger directly at the person who made the change? We typically miss the fact that it’s at least three people who should have caught the issue, not one. But even that is avoiding the point.

Most developers who take pride in their work will not just “shrug off” the issue that they caused. In the past when I’ve made mistakes, I was my own worst enemy. I would reflect and beat myself up over the mistake that was made to determine how I could have tested or planned better so I don’t make the same mistake again. I didn’t need other people to jump on the bandwagon to point out that I did it. That just helps to dig you into a deeper and deeper hole. A team is there to support each other when we are down, not bury them even further.

I still remember one day in the office when a data load bug had crept into the system. We basically had two changes going in that were in very similar areas (it does not help that they were in SSIS packages which are impossible to merge). Once they were merged into the main branch, the build/automated test runs of the data loads started failing. So firstly, this is great! Our automation spotted an issue before it hit production. And then, the blame game happened. Because the two people were on two different sprint teams, it became a bit of a political thing of “who did it so you have to fix it”. The worst part was, the developer doing the blaming felt like they were out for blood, the target of the attack, my teammate who was a much more soft-spoken developer so they wouldn’t defend themselves. They were defeated and being beaten down.

At that point, I just said, and continued to say “I don’t care who wrote the code, this is where we are right now, how do we fix it”. Finally, after about 10 minutes of the insistence of finding fault, we moved on to the “how do I fix it” phase. To this day, I see no value in the conversation which went on for way too long finding the blame, it was simply wasted time.

I still have some people who ask me, “who made the change”, when a bug is introduced. My answer is always “it doesn’t matter”, or “I don’t know”. Yes, if I really wanted to, I could find out, but for the development of an application, it truly does not matter. All it will do it tarnish a developer’s look in their eyes, when my entire team are the ones that accepted the change in.

The blame game does nothing but hurt other developers in order to build other ones up and should be avoided at all costs. When in a situation where there is an issue found, don’t ask “who caused it”, ask a more constructive “what can we do to fix it”. This will help lead into more healthier conversations.

Software development is a mostly “behind the scenes” operation. This is great because we don’t need to be in the limelight to do our job, nor to be good at it. But, this also opens up the door for other possibilities as well.

We have a lot of different tools at our disposal for the code that we write, and with those tools, we also have a responsibility to use for good. And guess what, we are also human. So, we make mistakes!

When doing anything in life, mistakes are inevitable. They are made in every occupation, it’s how we react to them that matters. Unfortunately I’ve seen countless times people trying to “protect themselves” by covering up the mistake. We have the tools available to us to do some of this. But I have to ask why is it necessary? Just because we are sitting behind a screen and can slave away for a few extra hours to remedy it, doesn’t make it right. Sure, admitting that you made a mistake is a bit of a slap to the ego, it should be! It further proves that you are not infallible. On the flip side, if you don’t admit it to yourself or just try to cover it up, and you are able to repair it it may end up actually inflating your ego. Telling yourself, “See, I messed up and was able to power through and fix it, I’m an amazing developer.” This however, is missing the point. It’s a learning experience for you.

The bigger issue that I find when people try to cover up mistakes is the fact that, it gets the problem solved today, but:

• What happens if you make bigger mistakes when covering up this one?
• What happens if you don’t even realize you are missing one piece of the puzzle? (i.e. if you are restoring data in a database, and return data to 2 out of the 3 required tables)

Problem solving is part of our job, and these issues could just be looked at as another problem to solve, which is fair however, not favourable.

What happens if you make a mistake that you can’t cover up? What happens if one of your co-workers find out that you covered something else up? That’s when things start to go downhill fast. Your reputation has been tarnished. The worst part about it is the fact people know you do this, so sometimes the unasked question (or asked question) is “what else did you cover up?”. This of course will instil doubt within your co-workers. They also will lose faith in you, and at this point it’s difficult to rebuild this trust. You built part of the working relationship on lies, and betrayed your fellow developers, how can they trust you?

When you do make a mistake that you are not a fan of, instead of covering it up, do the following:

1. Get a good understanding of the mistake that was made, so you are able to explain it
2. Come up with possible solutions on how to resolve it
3. Mention to your team that you made this mistake, and have come up with a few options and ask colleagues for their opinions
4. Work with your colleagues to resolve the issue
5. Come up with an action plan to prevent this from happening in the future

Yes, doing this may add a scratch on your reputation but it will also help to add a feather into your cap. You have shown your co-workers a vulnerable side, and that you are fallible. Because of that, they will, over time, trust you more. They will know you tell the truth and aren’t trying to save face. You may also become one of the people that they go to when they inevitably make a mistake.

Mistakes suck, but are inevitable as humans. It’s how we choose to react and grow from them which shows a level of maturity and integrity that you have. The initial ego hit sucks, but the trust that you develop as a team member will help to reduce the overall burn from this mistake.