Age discrimination isn't about competence (programmers peak much later than 40) but control. It exists because the VC man-child oligarchy (oddly enough, software inherits the age-discrimination culture from business-culture colonists who'd be "too old" to write code) thinks that people will work harder if this shitty, artificial time pressure is put on them. And, of course, much of the ageism and sexism is unintentional but still exclusionary. See: open-plan offices and the aggressive micromanagement of Scrum. I don't think Scrum and open-plan were devised with ageism in mind, but they contribute massively to the attrition. As people get older, they have less tolerance for macho-subordinate bullshit.
This macho-subordinate culture that is imposed on software engineers needs to die. It drives out an incredible amount of talent, makes us an HR nightmare as far as diversity goes, and it has nothing to do with programming; in fact, it detracts from the quality of what is produced. We have to kill it at any cost and professionalize our industry because we can't trust our financial backers.
I've got 30 years of experience at this point, and as a result, I grasp new technology faster than most; and the baggage of my years of hard lessons learned is of great worth to my team, employees and employers. As one might expect with any thinking profession.
Get the picture?
That's not just the software business.
That's the surface-level "technology" they (VCs) mean. VCs don't care about your deep algorithm knowledge or domain experience unless it can accelerate user-facing interfaces to the moon.
If you hire people with 30 years experience, do they know what a Gruntfile is? Do they know the difference between Gruntfile.js, component.json, and package.json? Do they know the relation between Docker and Vagrant and Kubernetes and CoreOS and rkt and etcd? Maybe they still love XML a little too much. Now they have to re-learn the same things they already knew, but with new fads and new syntax and new bugs built-in, all while trying to keep "old ways" vs "new ways" straight in their cluttered heads.
Even look a hyper-accelerated areas: Ember? Angular? React? React forks? Become an expert in any single one and you're irrelevant within 3 years unless you want to support "legacy" apps forever.
Saying "old" is confusing too. Is "old" 30 years COBOL experience at one company where they wrote everything themselves and can't think any other way? Is "old" 30 years of always chasing the latest fads, master of none?
If you have a long work history, and if you are good at something, there's a good chance soon the thing you're good at will be replaced by something you're not good at. Congratulations, now you are "old" and out of touch. Younger people created something new and now your experience isn't relevant. In a way, "experience" is a fool's game. Experience requires a fixed point of deep understanding, but while you're getting experience, the world is moving out from under you.
You're almost better starting off as a 15 year old who learns everything new with no historical baggage. Nobody wants to hear old stories about stacks of punchcards and time sharing woes when we've got to deploy and monitor 1,000 instances to AWS in the next 15 minutes. But, you can't go back and become a blank-slate 15 year old every 5 years when the fads change out from under you. Ergo, you're old and out of touch and worthless and go live on a programmer retirement farm in iowa because you're not a culture fit with the 22 year old CEOs anymore. yolo, and you wasted it by not becoming a billionaire by 28.
That doesn't mean all programming is like that though. For instance, you know what I was using for graphics programming 15 years ago? C++ and OpenGL. You know I'm still using 15 years later? C++ and OpenGL. They've evolved a lot for sure, but that knowledge hasn't become irrelevant.
Carmack is a great example of experience+useful. So is notch. But, they are both very tied to hardware, algorithms, and physical implementations of things so they have stationary expert-level targets.
I am using React/Flux a lot lately, but that is just one straightforward JS platform, and since in my opinion they absolutely nailed the "pit of success" it's no problem to learn it by making real applications.
When that's the case, you're either a high school or college kid who can spend all their time learning new things, or you are old and learn new things a few hours a week, maybe nights and weekends.
You can't compete with someone learning (and iterating!) 40-60 hours a week when you yourself can't throw away all your 40-50 hour per week obligations and responsibilities just to keep up with them.
A lot of startups really aren't doing anything that technically exceptional, but if you want someone to spend their evenings fixing bugs in your bog-standard Rails app, it's much easier to persuade the guy that spends them fixing bugs in bleeding edge javascript frameworks than the guy that spends them with his wife and kids.
This age trope seems to be from some early days when technology did move slower and people expected to spend their entire career working on the same technology. I've never had that expectation.
Anyone who thinks experience is worthless is an utter fool. My work hacking on an F# JavaScript compiler directly translated to doing massive CoW in-memory snapshots using immutable data structures in C#. My early work with SQL and transactions informed my approach to using atomic CMPEXCH to do optimistic in-memory commits, giving the entire app database-like MVCC transactional semantics.
All of that has been invaluable now that I do iOS development full time. Swift's approach to value types and mutability are natural fits to a wide range of things (like undo stacks and concurrent background processing while publishing consistent changes to the UI). Different platform, language, tools, etc but the experience was far from wasted. Hell, having done manual memory management back when iOS was an after-hours hobby project gives me the tools to find memory corruption bugs and diagnose crashes in an hour that some struggle with for days. Even within iOS there has been massive change and upheaval. There again, experience with generics in C# pays off.
Doing full stack development, writing JS libraries, wrangling with CSS... It's all been valuable experience.
On the other hand, being old means you can quickly spot how trendy magpie technical stacks map to old patterns that the industry has been consistently reinventing over time.
It's also debatable just how many startups actually have much of the contemporary DevOps and data center infrastructure as part of their standard workflow, as opposed to all the volume of buzz that goes into discussing it.
oh, gosh. That too. The other big problem we have with so many "new" programmers is you can get a critical mass of a few million users before a platform even makes sense. Go shouldn't exist (Erlang did it first). MongoDB shouldn't exist (no explanation needed). But, they scooped the kids early then everybody starts "thinking" that way and before you know it, the world is stuck in a broken mindset.
Now, with an army of 5 million unknowing people committed to your platform, the people with experience don't matter anymore. You have strength in numbers, not in correctness or long-term viability.
It's also debatable just how many startups actually have much of the contemporary DevOps and data center infrastructure
Startups, yes. Actual companies, no. Most "real" companies (older than 8 years) have legacy infrastructure, physical data centers, and are only now realizing what 'cloud' (or OS-level VMs!) could mean to them (continuous deployment, automated testing, application isolation, reproducible infrastructure, etc).
Moreover, it's one of the few languages so far that have a near complete POSIX/Unix-like kernel(s) API so that one can do straightforward system programming tasks without C, without even using libc, much less meddling with FFIs, lousy wrappers and whatnot.
Also, I'm pretty sure OS-level virtualization has been popular for a while now. Hosting companies have sworn by OpenVZ and even Linux-VServer for ages. However, those aren't as straightforward to configure, nor do they have the marketing angle that Rocket/rkt and Docker do. They're also more system-oriented as opposed to app-oriented.
Total agreement is not needed on which skill goes in which category. What is very important is that you don't try to assert that there is a third category of things older people are worse at and are legitimate business concerns. That would be ageist and invite downvotes.
The proper flow seems to be: have experienced people who are better at strategy mentor inexperienced people who may know more modern tools and are better at immediate tactics (regardless of age), then over time the inexperienced people grow to become mentors to the new batch of inexperienced people.
But, in our current climate of ego-driven "22 year old amazing CEO knows everything with zero management training or management research," we end up with perpetuation of subjective confirmation-bias fueled "only 22 year olds can do everything" lies.
The youngest people are banging out feature #4,501 for the website.
As you get older you should be spending more time experimenting, teaching, mentoring, reviewing and building foundation.
The senior guys are senior not because they've pumped out more features this year, but because they're making all the engineers around them better.
But once you learn a paradigm, variations on a theme tend to take "about a week or two", and almost all this new stuff is variations on existing paradigms.
We know that doesn't happen for everything, but the problem is that it isn't somewhat predictable. We're pretty much in a lottery until the industry becomes insensitive to new tools which could take decades or more and we all have our own opinions on the safe bets and the risky bets. Maintaining legacy code sucks but it will at least get better because in two decades, the legacy code then will still have decent tools supporting it. I look forward to maintaining .Net 4.5 code in particular with visual studio 2013/15, despite that visual studio 2030 would be available. The IDE for my current legacy code responsibilities has a blazing white (#FFF) background with small font, non-monospaced black (#000) text. Kill me.
It's to the point now that if you gamble on investing time in new languages/tech, you have to plan to be out of a job while you retrain if something happens to your corner of the industry. Don't get me wrong though, churn like this is good because it's evolutionary. A new language isn't exciting any more because there's so many of them, but when one does make everyone excited, it's easier to see if it's worth the time. Eventually we'll get to the point where the idea of making a new programming language just isn't worth it because our normal set of tools are just so damn good.
There is a lot in software that takes more than 3 years to learn: machine learning (real ML, not tweaking off-the-shelf algorithms) and compilers and the like. The problem is that the man-child oligarchy that has taken over Silicon Valley (and, because of SV's influence, the industry as a whole, at least culturally) doesn't value fundamental or technical work (as opposed to doing "make the thingy work with the other thingy" Scrum tickets for a PM barely old enough to drink) so there are so few people doing it, and the competition for positions in real programming is quite high (and the salaries, sadly, aren't as good).
It's easier to get a real programming job at 30 than at 22, but fake programming jobs outnumber real ones by such a large margin. And when you're older and have a family to feed, being too old for the well-paid but fake programming jobs at the Hoolis becomes somewhat of a problem, because real programming jobs are so rare that it sometimes involves a cross-country move to get one.
Ergo, you're old and out of touch and worthless and go live on a programmer retirement farm in iowa because you're not a culture fit with the 22 year old CEOs anymore. yolo, and you wasted it by not becoming a billionaire by 28.
I think that attracting the "old" programmers to a specific city (possibly in the Midwest, say Chicago or Minneapolis, but possibly one overseas like Budapest) is the first step step in taking over the world. I'm not sure what the second is, but an industry that tosses people out just as they're beginning to get good at their jobs is (fuck this term in general, but here it applies) ripe for disruption.