Too much fad and hype driven development these days.
The field changes, it's changed significantly since I started 10 years ago. Yet there's a fairly large contingent of devs that aren't keeping up. I've interviewed old devs that are at the top of their game and old devs that are no better than the interns we have. I've worked with the same.
Another thing I've seen is people complaining about "old geezer not keeping up" is used to shut down conversation about whether $new_fad is really the best choice, and $old_thing may actually be better. Not saying that was your intent, but I've seen it used like this many times.
Not all that many years ago someone saying "no thanks, I'll stick with SQL instead of no-SQL" and even "no thanks, I'll stick with Java because I think the static typing is better" could be seen as "not keeping up".
This is why I tried not to classify this as a young v old thing. I don't think it's the case that old devs can't keep up. I think it's the case that some devs don't keep up regardless of age.
For young devs, it's hard to know if that's the case or if it's simply inexperience. For old devs, it's far more glaring when all their experience is with VB6. I think that's where a lot of the ageism in software hiring practices comes from.
> Not all that many years ago someone saying "no thanks, I'll stick with SQL instead of no-SQL" and even "no thanks, I'll stick with Java because I think the static typing is better" could be seen as "not keeping up".
Perhaps some saw it that way. I never did. I would say that if you were completely unfamiliar with no-SQL, you likely weren't keeping up. Just like if you aren't aware of k8s or docker today, you aren't keeping up. Whether or not you chose to use those techs is entirely different from simply outright rejecting them without evaluation.
They lack foundational software engineering knowledge/opinions
Use their IDEs as if they saw it for the first time
Lack of experience when it comes to architecture
I've seen people organize their data in a cache-pessimal way in order to squeeze out a couple of CPU cycles, for example. It becomes really tiring when you constantly have to whip up a benchmark just to settle debates on things that have been common knowledge for basically forever now.
You can argue everything with "because of performance reasons" because it requires way more effort to actually check it.
I always become suspicious when a software engineer has been working on a problem +10 years. The type that spend their time upgrading angularJS to angular or something like that.
[1]: https://news.ycombinator.com/item?id=4627373
[2]: https://ask.metafilter.com/62762/What-is-the-source-of-this-...
Phone development is a continuous slog through ever-changing APIs. An older programmer hardly helps here. In fact, this is probably one of the few places where I might agree that younger programmers are better--it takes an enormous amount of energy to keep up with phone programming changes and that's something that youngsters have aplenty.
Web programming is a similar treadmill except for the fact that you can opt-out. If the client demands some fad technology, well, then experience doesn't matter. If the client simply wants a solution, then experience can be a godsend. I've watched a couple experienced programmers deliver amazing web solutions really fast--they used well-trod, boring technology that they knew very well.
Embedded programming simply demands greybeards. I haven't seen an embedded project yet that succeeded if it didn't have a majority of people with 15+ years of experience and couple above 25+ years. So much will go wrong that it's more important to design around the failure modes up front--and you have to have been around the block a couple of time to understand what those are in order to avoid them.
This is a good thing, in my opinion. Not only does reinventing something give a new generation an opportunity to learn how to design, but it also gives that new generation context and knowledge about the product when it is complete.
> we don't learn from previous generation's experience
This is a serious cultural failure (and it happens globally). Very few of us sincerely engage with the past, in my opinion, because it takes a lot of effort to do so. And either it's not worth the effort on an individual level, or we haven't been allocated the time/resources by management that it would take to sincerely engage with the past.
Without being too reductive, software is subject to the theory of economic profit and thus tends to ~free.
Churn is the natural response. It artificially create the sort of work that forces users to spend money in the future.
Most of the material out there on YouTube, books, and blogs seems mostly dominated by younger people (30s and below). I'd love to see people who really know what they're doing put out some material.
Also writing books is something you need to enjoy or at least feel driven to do. For most people it's not worth it in a monetary sense either.
In the long run it might be better to treat software as "fast fashion" rather than something meant to last forever.
Ostensibly nothing, so long as you can tell when things are better. If you're trying new things and taking on new, better ideas quickly then you'll improve rapidly. If you're also "failing fast" and throwing out new things when they don't work then you'll improve even more rapidly.
If you're abandoning good tech simply because it's old, and not fully understanding the drawbacks of the new things you're switching too, then you're building an empire of tech debt that all your good team members will eventually get sick of fire fighting and they'll leave.
Novelty doesn't make people loyal. Working on strong tech that people are proud of does. Sometimes that requires a deep dive into some tech over a number of years.
The "flavor of the month" band wasn't as good as The Rolling Stones. That's not the end of the world if all you did was buy their CD, and then never listen to it again after the month was up. If you completely rebuilt your stereo to try to make that CD sound better, though, that gets more expensive. (Especially if you rebuild it again next month for a different band.)
Development is more like rebuilding the stereo than buying the CD. It's expensive. It takes time and money that could be spent on other things.
Worse, in replacing dependencies, you may replace a dependency on something that works with a dependency that doesn't work nearly as well. You may replace your Corvette with a Corvair. (And spend time and money to do it.)
If you have battle-proven tech, there is a place for eventually replacing it. Eventually, though. Not very quickly. And when you do replace it, don't replace it with the fad of the month (or even the fad of the year).
That is what is wrong.
> Pete concentrated on building a system [in COBOL] that works for him and his clients.
If that system isn't replaced before Pete retires, it turns into a significant hidden risk.
You don't know how dependent on something you are until you try to replace it with something else. If hype is driving the replacement, so be it. An organization can make replacement a regular practice and get good at it; or it can find out when it unexpectedly becomes necessary.
https://www.microfocus.com/en-us/products/visual-cobol/featu...