Good software has a texture to it. You can feel it when you open a file and the code makes sense before you've fully read it — when the names are right, the abstractions are calm, the structure doesn't fight you.
This is harder to teach than any technical skill because it isn't really a technical skill. It's closer to taste.
What staying power looks like
I've worked in codebases that were five years old and felt contemporary, and codebases that were six months old and already felt like archaeology. The difference was rarely the language or the framework.
It was whether someone, at some point, decided to care about the next person who would read the code.
// Not this
const d = u.prefs?.notif?.email ?? false;
// This
const hasEmailNotifications = user.preferences?.notifications?.email ?? false;
The second version takes four extra seconds to type. It saves minutes every time someone reads it.
On naming things
Kent Beck said that naming is the hardest part of programming. He's right, but I think the reason is underappreciated: naming forces you to understand what you're actually doing.
If you can't name something clearly, you haven't understood it clearly. The fuzzy name is a symptom, not the disease.
The name of a thing should tell you what it is, not what it does. Functions do things. Things are.
The patience problem
The real obstacle to lasting software is time pressure, which is a business problem masquerading as a technical one.
Writing software that lasts requires the discipline to slow down when everything is telling you to go fast. That's a cultural thing. Teams either value it or they don't.
None of this is new. But it's worth saying again, because the average codebase I encounter suggests we keep forgetting it.