Buffalo buffalo buffalo

"Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo" is a grammatically correct sentence in English, often presented as an example of how homonyms and homophones can be used to create complicated linguistic constructs through lexical ambiguity
— Wikipedia

This is what a lot of code looks like and too few people seem to care.

We use words like "utils" and "data" to mean literally anything and everything, because in reality they do. Not in the sense that they can be any part of speech, but that they're literally the building blocks of software. In the most fundamental sense, software is about giving data utility. Sometimes I feel like the only reason programmers don't call their classes Class and their functions function is because these concepts are built into the language, and it would look obviously redundant and tautological.

Programming is about finding, describing, and sustaining boundaries where there are none.

Every single computer program that's ever been written could, in principle, look like that buffalo sentence - perfectly homogenous and isotropic. Compilers and interpreters do not care, which is why minifiers and obfuscators can exist. Every software system could be just a solid block with no discernible parts.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
— Martin Fowler

We break it down for ourselves and each other, to make our job possible. The job of unambiguously communicating business rules and allowing them to change as quickly as possible. I will keep repeating this forever:

The job of a programmer is not to make a computer do something, but to make a computer do something else.

As programmers, we build worlds from words and we must consider the words we use carefully. Moreover, since software is about change, we must consider the words that have already been used carefully as well, regardless of whether it was us, or someone who came before us, who used them.

More often than not, refactoring is not about working with the concepts that are already there - it's about renaming, redefining, and deconstructing those concepts.

That's why the idea of "making the change easy" is so important, because it boils down to rethinking concepts right where they start becoming a nuisance, but before they grow workarounds.

I recently read on Twitter, and I can't remember who wrote it, that the worst way to let your users down is to keep bugs around long enough for them to work around the bugs. But this is also true of programming itself - if you keep wrong concepts, wrong abstractions, around long enough for a thick layer of workarounds (aka, difficult changes) to grow around them, they become nearly impossible to fix. They become architecture — decisions that shape the system and are hard to change..

All of this boils down to two things. First, remember that the purpose of software is to change and second, make sure you constantly challenge the words and concepts you want to put into the software, as well as those that are already there. Especially through the lens of how they relate to each other. What used to be a single concept a month ago can grow into 2 loosely coupled concepts, or the other way around, now.