I currently work with senior engs who are really more like reworked mech engs.
Who want to use old versions of eclipse, on win8, install new copies of the same for diff projects, want the new associate level engs (23yo, first job, etc) to write plugins for that old eclipse so the shipped plugins that break due to age still work. Because they dont know svn command line, or how to merge without the plugin.
Won’t migrate to git from svn - though that’s ok, we don't “need” distributed vc. They still think git history is so mutable its “spooky.” Though I’d love to make branches while working from home and not on the vpn…
In short, and it’s just one story, really: this kind of thing happens at all levels and is really a management issue, imho. They should be pushed to expand knowledge as a priority in the workweek.
Often we’re just tossed into “fix it ship it” mode and before we know it we’re 60 and cranky and yelling at clouds.
Perhaps these devs prefer the "fix it ship it" mode and don't see the value of learning particular skills. I find it a balancing act to be pragmatic and it involves being skeptical about investing time learning new tech. With everything there is to possibly learn, you have to ignore almost all of it... until (at the latest) it's industry standard in the niche you specialize in and then you have to be open minded that it's worthwhile to the company and personally.
I have found in cultures like you describe "decision matrices" can be helpful because it allows people to consider costs, risks, do preliminary investigation, etc. That is a sort of way of providing encouragement and permission to learn things and innovate. Lunch-and-learns are another tactic to force people (or give them an excuse) to learn. Neither of those should need managers' approval to do (it's just creating a meeting invite for lunch or a wiki page). If these don't work the problem is probably the seniors internalizing management's whims instead of pushing back. But the engineers won't push back if they've never taken time to learn.
Solid thoughts - I neglected to let on that in my case the seniors lament about how new tech sucks, like python being just another perl… etc. They are “tear down prove it to me while I call things retarded” sometimes.
Thats where mgmt should step in. Its really only a couple people.
You might be surprised how even people as aggressive or stubborn as this might still find it embarrassing or unreasonable to refuse a lunch-and-learn. Maybe sending a mass invite to a meeting on Python would be seen as passive aggressive, so just start socializing smaller ideas with key people. It sounds like you'd have to be cautious about upsetting people but I think it's always worth it to at least find the most polite and diplomatic ways to suggest things you want at opportune moments. The times I see this backfire is when people let it monopolize their attention or bring negative tone/attitudes.
Who want to use old versions of eclipse, on win8, install new copies of the same for diff projects, want the new associate level engs (23yo, first job, etc) to write plugins for that old eclipse so the shipped plugins that break due to age still work. Because they dont know svn command line, or how to merge without the plugin.
Won’t migrate to git from svn - though that’s ok, we don't “need” distributed vc. They still think git history is so mutable its “spooky.” Though I’d love to make branches while working from home and not on the vpn…
In short, and it’s just one story, really: this kind of thing happens at all levels and is really a management issue, imho. They should be pushed to expand knowledge as a priority in the workweek.
Often we’re just tossed into “fix it ship it” mode and before we know it we’re 60 and cranky and yelling at clouds.