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. :( Too often they'll bristle at the mere suggestion that they should keep the dedicating an hour or two of their spare time each week/month to reading and learning new things.
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.
My uncle is in his early 50's and is a Cobol programmer. Been doing it for a long time now. For him, programming isn't fun any more. Its just a way to make a decent living doing something he knows well. But he really doesn't like it.
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.
I'm 49 also, and I still write C and Python. I also have a lot of experience of scaling things operationally, so we have many things to provide. I love learning the new things, if they help me do my job better - like git (HATE svn. HATE). I quickly can spot the fads and will look at them and wait (scala, erlang) for the right place to use them.
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.
Why should they do this in their spare time? If it is important to the business, shouldn't the employers provide time for their employees to learn new technologies?
This is one of those assertions that is simultaneously true and irrelevant. A developer who is comfortable in git is better than a developer who's only willing to use Clearcase. How they get to be one or the other doesn't play into the value calculation. "That's not fair" is one of the least compelling arguments in business.
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.
Thomas, this is totally irrelevant, but would you consider yourself one of those "older" developers? I'm intimately familiar with your comments, but I have no idea how old you are.
> 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.
Who would you rather hire/work-with?
* the developer (of any age) who keeps up with technology in their spare time
* the developer (of any age) who refuses to keep up with new technology or who demands that the business provide the time for learning new things
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.
Because employers could just replace you. The same way a person is supposed to take care of his own choice of career and the education that goes with it, one should keep up to date with the novelties himself.
Of course, if we are talking about some obscure technology/process that the employer has chosen (ISO 98823:4343 for example), then the employer should provide the training.
Because the business will be able to find someone who is willing to learn in their spare time. Besides, the great thing about being a programmer is not that you have to learn new things but that you get to.
"the business will be able to find someone who is willing to learn in their spare time. Besides, the great thing about being a programmer is not that you have to learn new things but that you get to."
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.
I don't know if you can draw that drastic of a conclusion from his post without some other knowledge of his particular situation. For some people Git offers very little advantage over SVN, a small team with a single desktop or embedded produce is not going to see the same advantages of a DCVS system that a massive web team does that is seeing daily releases. As such a developer with their use case may feel that the effort to learn it for their situation was not worth the effort.
"For some people Git offers very little advantage over SVN, a small team with a single desktop or embedded produce is not going to see the same advantages of a DCVS system"
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.
There's nothing wrong with requireing your employer to do that. To me, it seems like a transition away from being an engineer to an employee. Keeping up with the latest and greatest, learning new stuff keeps you active in your profession. When you're passive about about that stuff, your job hunting prospects decline. In the worst case, you're literally totally dependent on that single employer, because there's nothing else you can do.
I personally don't agree with this, I think as a professional it is our obligation to keep our skills relevant by whatever means, if we want to work on newer technology. If we don't we can choose to sunset. That being said, when I am in an authoritative position in my organizations I always give my developers free time to improve skills but I personally don't think it should be expected.
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...