The Fine Art of Breaking Things (and Letting Someone Else Take the Blame)
There are many ways to be a genius. You can be someone who uses their talents to work hard and deliver value to their whole organization. You might be someone who is a great team worker, connecting people in the company and helping others to be the best version of themselves.
Then there is that certain kind of genius. The wizard who seems to do very little, and shifts responsibility just enough so that someone else gets blamed when things go wrong.
This article is a tribute to those people I’ve come across in my working life, and I’m sure you’ve met some of these types of people.
The Fix, That Fixed Nothing
Most software engineers I know feel that the whole place is stuck together with bubble gum, but there are a few places where this is really true.
The places with the worst spaghetti code and poor practices are those where people make quick fixes that aren’t really fixes. They patch systems in a way that fails to hold everything properly together, and code improvements that work perfectly except for the fact they break at the first inopportune moment.
Now in healthy environments, the responsible engineer is responsible and works to fix the problem and owns whatever is needed to fix the issue. When you’re in a poor environment you’ll find an engineer who knows the issue is not their problem anymore, because they’ve found someone else to give it to — if you hadn’t guessed it that person is you. They will be highly skilled at this practice and may even be able to make the whole mysterious failure look like your fault!
The Blame Game
The most fun blame game is when the person who actually caused the issue swears up and down that it was working fine when they left and leaves you with the hot potato.
“Oh, that bug wasn’t there when I worked on it.”
“Strange, it was totally fine earlier.”
“Are you sure you didn’t change something?”
Yes, I’m sure. And I’m also sure that the system logs say you were in here three days ago applying a “quick patch” and you “forgot” to add the unit tests in I see.
The Secret Philosophy of Fixing Just Enough
The true masters of this craft follow a few simple principles. Please don’t use this as a guide, I’m putting this here, so you know what to look out for in future.
Apply the least amount of effort possible
If it looks like it’s working, it’s working. No need to investigate why.
Make the problem appear fixed
Not actually fixing it, mind you, just enough that no one questions it until later.
Ensure plausible deniability
If something breaks, make sure it happens far enough in the future that you can claim total ignorance.
Always act surprised
The golden rule. When it finally collapses, pretend to be just as confused as everyone else.
The Relay Race
You can make the blame game into a fun relay race! This is a time-honored corporate tradition that has been passed down through generations.
The IT department hastily patches something, and when it fails, blames the most junior developers for not following “best practices.”
The engineering team rushes a software update, and when it introduces more bugs than it fixes, blames product management for unrealistic deadlines.
Management makes reckless cost-cutting decisions, and when it all goes wrong, blames employees for not being adaptable.
Everyone is fixing just enough to survive another day, passing the buck until someone else gets stuck holding it.
How to Protect Yourself
If you don’t want to be the next poor soul who inherits a booby-trapped project, consider doing the following to make sure that you aren’t caught in this blame-game nightmare.
Document everything
The moment you see someone implementing a questionable fix, make sure there’s a record of it. Bonus points if you send a friendly message with “Just checking on that quick fix you did…”
Never trust “quick and easy” solutions
If something was truly easy to fix, it wouldn’t have been broken in the first place.
Make them explain the fix
Ask detailed questions. The vaguer their answers, the more likely they’re just trying to push the problem onto you.
Prepare for impact
If something feels like a ticking time bomb, it probably is. Have your escape plan ready.
Conclusion
As long as workplaces exist, so will the noble tradition of fixing things just enough to make it someone else’s problem. It’s the corporate survival instinct at its finest because why actually solve an issue when you can just delay it? Eventually, everyone gets bored and moves on, leaving you free to push the features that you enjoy working on. SCORE!
So, next time something mysteriously breaks right after you start using it, take a deep breath. Somewhere, someone is watching, smugly sipping their coffee, knowing they got away with it again.