Don't be too quick to blame... it's rarely that simple

Full article

We all know people who are quick to throw blame around. When they find a problem, their instinct is to find the culprit - and make it clear who isn't to blame! Having worked as a programmer for quite awhile, I'll admit to spending a little time on both sides of that blame game.

It's especially embarrassing when you're on both sides at once. You're tracking down a bug and at some point in the process the code starts looking eerily familiar. You begin to wonder... maybe.... but it couldn't be... did I write this code? Then you type git blame (awful name, btw) and hold your breath......

The next time you find a piece of bad code, before you embark on a holy crusade to find the evil perpetrator, keep these things in mind:

  • No one sets out to write bad code.
    Sure, there's plenty of examples on TheDailyWtf and reddit, but very few people intentionally write bad code. Maybe they were inexperienced. Maybe you know something they don't. The real problem is if they have no desire to learn.

  • No one writes code without a reason.
    If the code is there, someone was trying to solve a problem. It might've been something that bothered them... or something that bothered the whole team. More likely, someone asked them to write that code to solve a real business problem, and you don't know what that problem was. If the team has had turnover and the department changed bug tracking software several times, it may be near impossible to know what the original problem was.

  • No one should merge code on their own.
    The more eyes, the merrier... aka pull requests. If a bad piece of code made it into production, it's everyone's fault to an extent. If your team doesn't do PR reviews, start. If your team does do PR reviews, then everyone agreed it was good once upon a time.

  • Requirements change.
    A particular solution might be perfect at the time it was written. Then requirements around that code changed several times. And requirements around a tangential piece of code changed several times. Lo and behold, soon the original code isn't so perfect anymore... but that doesn't mean it never was. These kinds of issues are exactly why we're hired... it's our job to make it the right solution again!

But if after reading this, you still can't resist a good ol' witch hunt, then at least be really sure. ;p


Grant Winney

I write when I've got something to share - a personal project, a solution to a difficult problem, or just an idea. We learn by doing and sharing. We've all got something to contribute.

Comments / Reactions