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.