This logic is so broken. Languages and dev platforms may change every 10 years. C++ may get stale. But image processing, or compression, or security, or low-latency high-throughput congestion-aware network protocols, or what-have-you don't.
Just don't pick things to specialize in that are guaranteed to date themselves. People who did program transformation masters theses in the mid-90's are just now coming into their own in the industry.
I asked this elsewhere, but I'll ask it again here, and I am being completely sincere. Why pick things to specialize in at the expense of other things you elect not to?
Specialization is not free; it decreases flexibility, and would seem that it would decrease cross-pollination of ideas from different areas of knowledge. It increases income, for sure, but also increases the attendant risk that people won't have need for an X specialist right at that moment, or at least no one you would want to work for.
I'll grant that generalization is not free either. Someone who really needs an X specialist will pay top dollar, because the supply is likely pretty low. And people may not trust a generalist to go and implement some specialized X performing application.
I think there are opportunities and attendant risks for both. I really don't think either one wins outright. But, I'll be happy to listen to words of wisdom you might have on this.
Really, your post answers your question. There is value (and risk) in either specializing or generalizing, and there is room in the world (and the job market) for both.
Personally, I am a database specialist. I do have skills in other areas (I do python coding as a hobby and I can write C# code that at least works), but my strong suit is definitely in databases, and even with databases I focus on MS SQL Server and Access with just a little experience in some others.
I personally chose to do that because databases appealed to me and by specializing I could gain a depth of knowledge that very few generalists can. In terms of careers this limits my options somewhat, but it means that within my particular domain I can out compete most others. When the company needs a generalist that can do a lot of things, I am probably not their best choice, but when they need someone with a deep understanding of SQL Server and relational theory then I am a good candidate.
None of what I wrote above exempts you from keeping up with the superficial trends of the industry. If things shift from J2EE to Python on the DLR with .NET libraries, you still need to keep up with that stuff. So yeah, if you're stuck with recruiters (and, don't be), be keyword compliant.
But the big scary force in this article is, "over 10 years, your C++ experience makes you progressively more expensive and less attractive to a Ruby shop". That's true, if all your 10 years were about was C++. C++ is a distinctly dumb thing to build a career around.
"C++ is a distinctly dumb thing to build a career around."
For that matter, so is Ruby, Rails, Python, and everything else that's popular today.
In ten years, everyone will be using Blub, and badmouthing those dumb ol' guys who were slogging around in Ruby. It's the one thing in life I can guarantee.
I agree completely, in case it sounded like I was just ragging on C++. When I do that, I accompany it with all the many reasons why C++ deserves the treatment. =)
So yeah, if you're stuck with recruiters (and, don't be), be keyword compliant.
Most recruiters and big company HR departments are among the biggest destroyers of meaningful language there are. "Keyword compliance" is just another of the forces trying to dumb us down and turn us into automaton neurons in a big brain, exchanging and processing signals we don't have any inkling of.
I got my first programming job in 2002, because I knew Pascal, If you where a consulting firm with 10k employees then you need to keep up with industry trends, but we are not. You can try and keep up with all the latest trends, but it pays better to focus on about 3 areas and know a lot about them.
Sounds to me like you and the recruiter have totally different target audiences.
Just my two cents, but I think you might be doing yourself a disservice by dumbing your resume down to their level... Unless the type of job you're looking for is just a cookie-cutter "latest pet framework" position.
But in a work environment it's often not your choice to pick what you work on. I tended to find that those with the experience were set on legacy systems, and the new technology went to contractors, or were outsourced. And no matter what your 'application experience', any chance at employment elsewhere became based on your 'language/platform experience'.
Just don't pick things to specialize in that are guaranteed to date themselves. People who did program transformation masters theses in the mid-90's are just now coming into their own in the industry.