We should all be more charitable. I’ve noticed that programmers can be quite uncharitable—uncharitable towards other programmers, uncharitable towards code, even towards companies. Code is always unacceptably bad. Companies are incredibly stupid, have lost their touch, and don’t know what they’re doing.

Let’s try to do better.

Before making a claim, let’s try to do our research, to ask our questions and to learn the full story. Let’s try to imagine a good faith reason why this situation occured. Let’s not fall back onto assuming stupidity too early. It’s easy to blame. It’s harder to understand.

Credibility

One may ask: Why should I be charitable? The code is clearly bad and the programmer should have done better.

Well, you could be wrong. Even at the worst companies, with the dirtiest, ugliest codebases, there is code with valid justification. And it doesn’t matter if you were right 95% of the time. If you call out code and are demonstrated wrong, your credibility will suffer.

Now, in a perfect world that would not be a huge deal. People are wrong and that’s fine. The world goes on. But if you’re in a place that is not very reasonable, as many companies with bad code are, then this is a big deal. You will be seen as the boy who cried wolf. Even if your colleagues continue to listen to you, there will be that nagging memory of the time you decried perfectly reasonable code.

Before committing to this claim, try to scope out the scene. Ask a person who is familiar with the code. Make sure you understand the technologies and the language. Make sure you understand the style and conventions of the team.

Try to think of the most reasonable, in-good-faith, generous justification for the code. Even bad code has reasons behind it.

Then, once you have done your research and asked your questions and thought through the justifications, only then should you raise the claim.

Chesterton’s Fence

You buy a piece of land and there is a fence on it. The fence has no apparent purpose. It does not connect to anything, it does not appear to do much.

What do you do?

Many would say to remove the fence. That is not the correct answer. You should figure out the purpose of the fence. A use that is not obvious is not the same as a use that doesn’t exist.

Go talk to the original authors. Find the purpose of the code.

Nice

It’s good to be nice. Being uncharitable is not nice. When someone is uncharitable to me, I don’t want to always explain gently why they’re mistaken. Sometimes I want to tell them to fuck off. That’s not nice either but I’m not perfect.

This won’t lead to anything productive. It’ll just lead to bitterness and anger and wasted time.

Even if people handle your lack of charity with more grace, it will have an effect. They might be less eager to share work. They might not tell you their ideas. They might withhold information for fear of your reaction.

We all like to pretend that we’re aloof adults with thick skin, but we can still have our feelings hurt. It still stings to have someone claim your code is bad.

Ignorance

Ask yourself, do I know enough to make this claim? Or am I unnecessarily confident in my ignorance? Dunning-Kruger is a real, valid phenomenon. The people who know the least can have the strongest opinions.

At the same time, don’t be afraid of having strong opinions. Just use them as an impetus to do research. Read various sources, listen to different people and if the evidence starts to match up to your viewpoint, then you can start making claims.

Use your viewpoint as a hypothesis, not a theorem.

Making The Claim

Once you have decided to make the claim against someone’s code, do it with tact. Do not do it in public. Do not cast aspersions. Do not make it personal. Try to keep an open mind. It’s quite possible they do indeed have a justification that you didn’t anticipate. If that is the case, withdraw your claim as cleanly as possible.

Try to phrase your claim as a question, not as an accusation. You’re attempting to understand the code and clarify intentions, not to blame or shame.

Negotiation

Everything is negotiable. Many developers take the absolutist view. They believe that code is either great or terrible. They believe that they must speak out about bad code. Perhaps it’s an effect of dealing with ones and zeros, true and false all the time. Regardless, it’s not a tenable approach. The absolutist will always have some bug to bear, some campaign to lead, an endless quixotic quest. No codebase is perfect. No product has enough features.

Software development is fundamentally about trade-offs. One trades off code quality for features, performance for developer time, etc. There’s no way to get everything at once. If someone promises you perfect software, you’re getting tricked.

Ask yourself if the flaw that you perceive could have been a tradeoff. The code that is ugly and flawed but makes the company money is more valuable than the beautiful code that sits unused, the company already having gone bankrupt.

The authors of the code may very well have known the issues you are raising, but prioritized something else entirely.

Of course the priorities may be different now. Code debt may be accrued up front but paid down later.

It’s Just Code

At the end of the day it’s just code. It’s not your life. Good code is worth aspiring towards, but it’s not your mission in life. Don’t take it personally.

When you decide to improve code, do it with patience and tact, with empathy and open ears. Be more charitable and hopefully others will be charitable in return.