This is some humble advice on how I believe people should deal with bad code.
It’s not technical advice. Actually it’s not really advice. It’s just stuff I’ve
been thinking of lately.
Typically, the first thing a person does when encountering bad code is determining
who they should blame.
Immediately it becomes a personal or tribal vendetta.
“Who could be so foolish?”
“Who is responsible for exposing my brain to such incoherence and blasphemy?”
“Who insults the house of <Insert Team Name>!?”
This is wrong. This should not be the first step. A deeper understanding of the code
is necessary before we identify the poor soul who should suffer your wrath.
Understand the code
Too often a programmer is sure. People generally are quite stubborn, but I find programmers
to be more-so. Programmers mostly deal in absolutes so I guess such confidence is understandable.
Approach the code with curiosity and a yearning to understand. Empathy for the person
who wrote the code would help too. Imagine yourself in their shoes. They may not be
anything like you. They probably care about different things too. They probably don’t have
the same streak of what you call perfectionism. Their capacity for caring may be directed
somewhere other than the whitespace that nestles their parentheses or the seemingly incoherent
naming of their variables. Maybe they have a life.
Without empathy you are not going to understand the code, nor how it came about.
You will simply sit there vocally festering in your self-appointed superiority.
Really understand the code
Do you want to understand why there are such rampant GOTOs, such deeply nested switch statements,
such obtuse naming, such ugly spacing?
It’s dead easy to understand. Just imagine that the code is yours and that you’re
trying to rationalise your own stupidity. Eventually your mind will fathom sensible
defenses: “I was being rushed”, “I didn’t understand the API”, “I didn’t have sufficient overview of the domain” …
Before you know it you’ll have a battery of excuses, and quite a few of them will probably
touch on the truth. You could have written code this bad. It’s not beneath you.
Question the approach, form an inquiry
As if you were a biologist discovering a new species that had evolved through millenia,
without a watchful eye nor guiding hand. Such a creature begs questions. Such a creature
begs inquiry. Of course, with code, you can just ask the author what their intentions were,
and this is probably what you should do.
Yes, it’s crazy, but true. You can approach the author and ask them. I must warn you though:
this may force you to take a slice of humble pie.
But what if there is no good reason. What if it is, in fact, laziness, or ignorance, or worse,
Yep, I’m afraid so. Now that you’ve discovered the error it falls on you to spread
your wise words so that nobody may befall such crappy code again.
Don’t let your ego play you though. Don’t email the entire team. Don’t shout from the
rooftop. Don’t write another blog post. Your biggest mistake is believing that:
- People don’t already know the pearl of wisdom you’re about to share
- People will sit there are willfully accept your patronising tone
And if you have to email everyone. If you have to shout from the rooftops. If you
must write a blog post about a topic that annoys you so, please remember
to inject parody and hints of self-deprecation so as to to disguise your ego’s intent.
If you were to write an article you should title it genuinely though, so as to entice
the stubborn programmer to read your post… something like “how to deal with bad code” would work well.
Seriously, you’re crap too
Yep, sorry. You’re crap at many things. Yeh, yeh, you’re good at some stuff, but you’re pretty
crap at everything else. Don’t blame others for not being as great
as you think you are. The truth will hurt in the end. That you are in-fact the same blubbery
mamallian mass as every other programmer,.. as every other person.
Now for some more delicious humble pie…