Most programmers definition of "highly skilled" is more like "proficient with a language", or framework, etc. A lot of people I know aim for "can use stuff" rather than "master this thing", which is mostly because, hey, it's technology, and there's always a new thing.
But there are skills past simply becoming proficient in new tools. You could "master the tool", like knowing the details of the JVM memory model, and very importantly, be capable of identifying very hard problems that you can solve that those "young guns" can't.
It is incredibly rare for me to find an experienced programmer that can sell anything but their past "obsolete proficiencies" to me. Most of them sell me on the fact that they've simply been good with X+Y number of tools, where Y of them are now no longer relevant. But they never focused on developing deeper skills that might have relevance (big data problems, etc).
It's the constant shift of tools that adds a lot of this tension. Yes, we need to be able to pick up new ones (languages, frameworks, etc) quickly, but if broad proficiency is how we define mastery, this has little relevance to businesses.
I'm not saying this is easy. How do you unambiguously describe a programmer's skillset past the languages and frameworks they say they know, especially in a way that might be "future-proof"? ("I optimized my system to display 30 frames a second!" "Wow, my phone does that now...") Ultimately, if we can't clearly describe why people's experience is better, it will be hard to justify paying them more, once you become proficient with that particular toolset. Thus, I don't sense real age discrimination as much as a simple inability to sell the value of our experience.
Of course, some programmers are WAY more valuable than others, so this is a problem that isn't just about age and experience. Hiring practices sure haven't matured at all during my 10 years on the job. But, until the finance guy can see why a guy with 25 years of experience but with 3 years with tool X is more valuable than the guy with only 5 years of experience but all 5 with tool X, well, you're not gonna see the money flow.
But there are skills past simply becoming proficient in new tools. You could "master the tool", like knowing the details of the JVM memory model, and very importantly, be capable of identifying very hard problems that you can solve that those "young guns" can't.
It is incredibly rare for me to find an experienced programmer that can sell anything but their past "obsolete proficiencies" to me. Most of them sell me on the fact that they've simply been good with X+Y number of tools, where Y of them are now no longer relevant. But they never focused on developing deeper skills that might have relevance (big data problems, etc).
It's the constant shift of tools that adds a lot of this tension. Yes, we need to be able to pick up new ones (languages, frameworks, etc) quickly, but if broad proficiency is how we define mastery, this has little relevance to businesses.
I'm not saying this is easy. How do you unambiguously describe a programmer's skillset past the languages and frameworks they say they know, especially in a way that might be "future-proof"? ("I optimized my system to display 30 frames a second!" "Wow, my phone does that now...") Ultimately, if we can't clearly describe why people's experience is better, it will be hard to justify paying them more, once you become proficient with that particular toolset. Thus, I don't sense real age discrimination as much as a simple inability to sell the value of our experience.
Of course, some programmers are WAY more valuable than others, so this is a problem that isn't just about age and experience. Hiring practices sure haven't matured at all during my 10 years on the job. But, until the finance guy can see why a guy with 25 years of experience but with 3 years with tool X is more valuable than the guy with only 5 years of experience but all 5 with tool X, well, you're not gonna see the money flow.