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.
