The “That’s just the way things are” Antipattern

Blake Venté
3 min readAug 20, 2023

--

Programming doesn’t have to be painful. Despite the impression that many many people have, there is absolutely no universal law that mandates that programming requires suffering.

Things are the way they are because someone decided to make it that way. Modulo physics and the fundamental laws of nature.

Does the Standard Model of Physics give rise to bad programming experiences? Absolutely not. Developer experience is bad when developer experience is not an investment priority.

The remedy?

  1. Writing descriptive error messages which explain why progress could not proceed and possible remedies
  2. Writing and maintaining documentation, especially documenting roadblocks and correcting errors in onboarding guides
  3. And in general Empathy for your fellow programmers, developers, and scientists

I heard this saying once: There are two kinds of people,

  1. “Wow that work was hard, let me change it so that no one else has to feel that pain again”
  2. “Wow that was hard, let me make sure it stays that way so everyone has to suffer like I did. Suffering builds character.”

I confess I once believed a form of this at one point in my life. I think we’ve all heard it. It is absolutely false that all suffering builds character. And even when (if) it does build character, it’s harder to prove that there was no suffering-free alternative to that same growth. Eliminating that paper-cut and making things as smooth as possible for people onboarding will allow people to face the real, important challenges elsewhere.

If you’re at a company that means less time spent debugging and more time spent building customer-impacting code, which gives you an advantage over your competitors.

If you’re trying to work at a company, that means less collective hours wasted debugging and more collective hours for contributing to open source, building your side-projects, and other impactful work.

Part of the answer lies in the radical humility of admitting, “I was stuck on this step so I opened a change request to the documentation.” And the attitude of leaving a space better off than when you entered it. Being willing to pay it forward is an essential part open source software and so much more.

So instead of “That’s just the way things are” let’s try “Oh yeah, let me add at least a quick remark about this in the documentation” or “We’ll add fixing this to the backlog and try to prioritize it when we have capacity.”

Feel empowered to bravely interrogate the status quo. Did we happen upon these conditions because they are the best? Or are there alternatives worth considering? And even if you find that it’s not worth it to change, you’ve learned something about the world along the way.

--

--