There's been a bit of chatter on the topic of being an old geek. As most people here know, code quality in the small is one of my favorite topics, and I realized after reading an article this morning that the two topics are actually significantly linked.
Kent Dodd's Why Users Care About How You Write Code hammered home something that took me a long time to learn. A lifetime, so to speak. There's a mantra that I've heard inside every enterprise I've ever been in: "Customer's don't care what language you use or your company's code style guides or your build system. They care about the experience." But Dodd's observation is this: if your system has poor abstractions, or is abstracted in the wrong way, then certain requests for future adaptations of your code are going to be difficult. Dodd's case is that "the experience of the user" is more than just what happens when they sit down with your software: it's about how fast you can innovate without risking the stability, security, or reliablity of the product. It's about having a relationship with the user that spans months or years, all the while your software is growing, adapting to new missions, and improving.
Knowing that these pitfalls exist is something that only comes with experience. Recognizing technical debt before it grows into a monster that eats up your development cycles is something that comes from doing this job for a long time.
Every startup that says greybeard geeks aren't a "cultural fit" is buying into the idea that it can outrun technical debt. That it doesn't need to mind its long-term, multi-release relationship with its users. Or that technical debt is something to be managed, something middle-management is going to deal with, and you can hire young developers and burn them out, and it'll all be fine.
It won't be fine. Experience matters. And more to the point, experience matters most to your customers, because without it, the experience your customers will have with your software will be as inconsistent and callow as the developers you hire.