When you join a system, you learn its words before you learn anything else. There is an Account, and it is not the same as a User, and neither is a Customer, and somewhere there is a Subscription that belongs to one of them and is billed against another. Nobody explains this. You absorb it from field names and function signatures and the way people talk in standup, and within a few weeks you are using the words fluently, which everyone treats as a sign that you have understood the system. It is at least as much a sign of something else: you have adopted its categories, and you will now do your thinking inside them.

That matters more than it sounds, because a name is not a label stuck onto a category that already existed. Most of the time the name is what made the category. Before somebody wrote Account, there was a continuous mess of humans, organizations, payment instruments, permissions, and sessions, with no seams in it anywhere. The name cut one shape out of that mess and made it a thing — something you can have one of, count, query, put in a table, and pass to a function. Every cut like that is a claim about where the joints are. Some of those claims are excellent. Some were made in an afternoon, by someone modeling a narrower world than the one you’re in now, and they have been load-bearing ever since.

The failure mode isn’t confusion. Confusion would be fine, because confusion announces itself and gets fixed. The failure mode is that a bad boundary keeps working well enough that nobody questions it, while quietly making certain designs unthinkable. If your system has one User and a user has one email, then the idea that a person might belong to two organizations under two identities isn’t wrong, exactly — it just doesn’t have anywhere to live. Nobody rejects the design. It never gets proposed, because there are no words for it in the local language, and proposals get made in the local language. The vocabulary doesn’t argue with you. It just makes some thoughts expensive to say and others free, and over a few years everyone converges on the free ones.

You can watch this happen at the seams between teams, where two vocabularies meet and don’t match. One group’s order is the thing the customer submitted; another group’s order is the thing that gets shipped, which may be three of the first kind or half of one. Both teams are speaking correctly. The mismatch surfaces as an integration bug, gets patched at the boundary with a translation layer, and the underlying disagreement — about what the business actually deals in — gets encoded as a mapping function and never discussed again. The translation layer is a monument to a conversation nobody had.

What makes this hard to fix is that inherited words come with authority they never earned. A name in a schema looks like a finding rather than a choice. It has survived, it is used everywhere, it has tests and documentation and a support team who says it out loud to customers — and all of that reads as evidence that the concept is real, when it’s only evidence that the concept is old. Age and correctness produce identical-looking artifacts. The concept invented carefully after long argument and the concept invented in a hurry look exactly the same three years later, and by then the second one has just as many callers as the first.

So the useful habit isn’t better naming, which everyone already agrees on and which only helps for the names you get to choose. It’s periodically treating the existing words as proposals rather than facts: asking, of a category you use every day, who drew this line, what were they looking at, and does the shape still fit the thing? Most of the time the answer is that it does, and you’ve lost ten minutes. Occasionally the answer is that you’ve been carefully solving a problem that only exists because of where somebody put a boundary in an afternoon, years ago, and never came back to check.