Its not hard, regardless of obligations outside of the office. You can't just sit back and rest on the stuff you learned 10 years ago...
Currently I write python, php, (and all the usual web scripting like js, html, css etc, etc) and c.
I've always written c. But spanning my carrer (life) I've written Assembler, BASIC, Xbase, Pascal, COBOL, & Ada. I've worked on various database systems including DB2, Oracle, Sybase and straight betrieve.
I've worked on various systems including (my very first HeathKit and TRS 80), Wang, Dec VAX, Netware, BeOS, IBM 360 and AS400's, most of the various UNIX's and of course all the popular OS's of today.
I use Git. I also use SVN. And I even use CVS (if I must).
This idea that us "older" programmers are resistant to change is ridiculous. If you want to get the "older guys" using Git explain why. I can't tell you how many times I hear younger programmers bashing other languages and tools. And rarely do they know what they are talking about.
PS: Let me add; I'm in management now - translation- programmers work for me. But I still write code. With them. On the same projects. For several reasons: (1) I enjoy it. (2) I better understand what they are writing. (3) I like to say to clients "I wrote that". That feels good.
I'm 44 and this is a very under-rated skill that older developers bring to the table. And one that only experience can teach. The grand-parent posted mentioned it as well when he talks about younger programmers bashing other tools and languages but rarely know what they are talking about.
I love hiring older developers for this reason. The problem is finding an older developer who 1) wants to continue to write code, 2) has kept up-to-date with their skills and 3) is looking for a job. That is a rarity indeed. Having just gone through the search for a new hire I can tell you there were plenty of older developers who applied that didn't have proper skills and none who kept up with technologies.
I've talked to him about learning some new languages and expanding his opportunities, but he's more interested in moving into some other kind of work like teaching.
I think it depends on the person, whether they do it for life or because its what they know.
Huh. I love to learn new things, but I hate learning boring technologies that re-solve solved problems. Especially when the old, boring technologies are serving me well.
If I could reclaim the hours I spent learning git (which is only a marginal net improvement over svn), I have a long backlog of CS papers about everything from image classification to distributed systems design. Those problems are interesting. Learning another version-control system is not interesting (and the same goes for: editors, make systems, debuggers, and to some extent, programming languages. I don't want to spend hundreds of hours learning another syntactic variant of Algol or Lisp unless I need it for something.) But now that I'm proficient with git, I can guarantee that some obnoxious fanboy is going to come along and force me to switch to some whizzy new version control system that promises to solve all my problems and give me a pony. It's the way of the world, but I'm still waiting for my pony.
When I was younger, I'd get distracted by any flash in the pan. Now I'm more conservative about what I'll pick up. Maybe that kind of conservatism is part of what you're paying for when you hire an experienced employee. After all, someone who won't waste hundreds of developer hours switching your whole company to the newest flavor of version control (without sufficient justification for the cost) is a benefit to the bottom line.
You sound exactly like the stereotype the original post describes.
I disagree, actually. Small, informal teams can use pretty much whatever they want with little penalty, and may actually benefit from having distributed repositories. Larger teams rarely need distributed version control (there's almost always a canonical central repository), and are also the ones most penalized by the complexity of git.
Git is a complex, confusing beast with a high potential for mistakes. There are some nice things about it, but (from personal experience) it also tends to create as many new problems as it solves. These problems are amplified on large teams.
> I always frown a little when my older (by a dozen years or so) co-workers get frustrated when moving to new tech, like git.
The business IS providing the time, they just don't want it. I'm sure most developers on HN has tried and been successful in getting their employer to try out new technologies (in order to learn) and paying for conferences and books.
If you don't jump at these opportunities and instead let yourself stagnate, you're gradually signing away more exciting career opportunities (including working in a startup) and the right to complain about your employer marginalising you over new hot-shot developers.
But then, I strongly object to the notion that older developers are likely to push back on (say) git. More likely, given the developers over 40 that I have known, is that the developer is likely to think that choice of VCS is banal; older developers are less likely to fetishize git or hg, which is a productivity trap for developers who are passionate about their VCS.
I know what my answer is.
To be clear - this is completely orthogonal to the question of whether or not companies should provide time for this.
I'm talking about the difference between someone who takes responsibility for their own career path vs. someone who expects the company to do it for them.