Me and a good friend of mine are principal engineers at our company. I tend to think we are well respected and have done a good job over the years. A few years ago we read our company’s job ads and realized that neither of us should even bother applying for our own jobs because our resumes didn’t have all the latest stuff that was asked for. Since then I constantly add new stuff to new projects even if it’s not strictly necessary’. One factor is to keep the resume up to date. Another factor is that you learn something and the new stuff may actually be better. You just have to be willing to back out. Microservices would be an example where a lot of people wanted to do it but it showed that in our case this architecture only added overhead without benefits so we scaled it back.
Resume driven development is a completely rational choice for employees. And companies have brought it on themselves with stupid job requirements and hiring policies.
Sometimes you let engineers do things that don't necessarily need to be done because it makes them happy.
Not everything that might make them happy, not the biggest most ridiculous thing they say will make them happy (but objectively don't actually know until they try), but a few things, and consistently.
What I see happen often enough is that someone who finally who has no fucks left to give takes big gambles to get permission to work on something, and what makes it resume fodder isn't that it does in fact look good on the resume, but that they have already begun to check out before the project even started.
With the exception of some progressives, almost everyone who talks about retention or revolving doors only start talking about it after the proverbial barn doors are open and all the best animals have already left. Nothing you do at this point will get back the people you couldn't afford to lose and already did. You're really fighting the last war at this point.
If you have to sneak tech that isn't vetted into projects, then you haven't made the case to management well enough, or management is running their company into the ground.
You'd be able to accomplish a lot more with a lot less headache and cost by vetting new tech before going full-RDD it in a critical system.
Also, as a company trying to hire people you need to use the latest fads to attract new employees. It is a vicious cycle for sure.
There is no room in this dysfunctional industry to use simple proven technology that is appropriate to your size.
I think you can definitely blame them and in fact I'd expect CTO's and managers to discourage employees from doing that. A small silly decision can later cost millions in rewrites or maintenance. In the end we'll all benefit if not every brochure website needs to have 50 micro services and use the latest nosql solution. We're the ones who end up maintaining these systems.
It comes down to whether you see the software you write or yourself as the important product of writing software. Paradoxically, I see myself as the most important product. Usually my work is a tradeoff between being productive and teaching myself. If I'm being too productive, I back off and experiment more and teach myself concepts.
You can learn Kafka, Map Reduce, Elixir, DynamoDB and shiny new JS framework X like Meteor or whatever, or you can just go deeper on the fundamentals and the traditional tech you already know (learning SQL to a deeper level, becoming really good in Java/.NET/PHP/vanilla JS etc etc).
I think the job market has room for both; and to me the second path is more enjoyable and sustainable but to each his own.
Developers complain "I need to learn NewTech because OldTech is old and no cool company uses it anymore." And hiring managers complain "We need to move from OldTech to NewTech because we can't find developers interested in OldTech anymore."
...and making good salary doing it!
That's not the only thing we should do, of course. Systemic problems are better fixed with systemic changes. But there's nothing wrong with holding people accountable.
Unless they have a real stake in the company (as in non-trivial equity grants) why the hell would they prioritize making you additional money (or saving money) by using tooling that will make them a less valuable hire in the future?
They are getting paid to accomplish a task for you, they are NOT getting paid more if they use tools that would be more effective but hurt their future prospects.
You can set guidelines around tooling if you want to prevent engineers from doing this, but otherwise assume that part of the reason they're willing to show up for the salary they get paid is to learn more and eventually make more.
If they can't make more through the company making more (equity) don't expect them to prioritize that.
Otherwise your take is meaningless.
Is it in the best interests to lose interested and engaged engineers but to save 10% on cloud computing fees?
Is it simply making the most money?
Is it picking a tool you're comfortable with, but is hard to hire for?
Is it accomplishing the "stated objectives" even when those objectives are wrong, or immoral, or illegal?
Basically - unless I have equity (and more than .01 of a %) then the "organization I work for" is ME. I'm managing my time, and renting it out to the current highest bidder. I will absolutely work to ensure that bidder is happy and satisfied with the results of hiring me - but I WILL NOT devalue future earning to do so.
Certainly you seem aggressively unaware of anything other than "the company", setting aside other relevant parties, like colleagues, users, and society at large. While also ignoring quite a lot of things that even engineers value in their work besides money.
Econ 101 is an ok first-cut model, but it's pretty bad as a religion. There are more things, Horatio.
Big ooof, given the entire discussion is predicated around using simple and plain tooling to save a company money, and then berating developers who dare to learn new tools on the job. It turns out part of learning is picking the wrong tool occasionally. Who knew?
I was brought in on a cleanup job a few years back and discovered that key parts of their infrastructure went through a system nobody understood and were scared to touch. It was using Docker, but for no obvious reason, and it was version-locked to a very specific release in the 0.9 series.
After some archaeology, I found the original commits. They were from an engineer who wasn't there long. On a hunch, I googled him. I found a video of a conference talk on Docker where he exaggerated the scope and value of what he had done. So I ripped it out again, making the system simpler, more reliable, and less scary for the staff.
"So tell me about a project at your last job?"
"I used Mapreduce to blah blah blah."
"So you had tens of billions of records?"
"Well, no."
"So why did you use Mapreduce over other solutions?"
"............."
You almost never get asked that in an interview though.
I'd love to be able to say this in an interview one day. And I'd be telling the truth (not about Mapreduce but something else, let me tell you about the time I lost an argument with a Senior/Staff Engineer who wanted to write an entire PHP library for log files on a single-serving linux host instead of using cron and logrotate).
But like you mentioned, it's a type of question I've yet to be asked. Depending on the room (ala "read the room") I might volunteer that bit of information in a more 'interview friendly' way.
Generally people tell me about the hot new XGBoost model they fitted, and I ask them how much better it was than logistic regression.
9/10 they don't have a good answer.
That being said, my favourite answer was from a candidate who told me that Kaggle contestants didn't use log reg, and therefore it was a bad choice.
Oddly enough, we didn't hire that candidate.
OTOH, I've worked at places where they wouldn't hire you if you didn't talk about your awesome neural networks/XGboost experience, so it really depends on the interviewer.
And then I would follow up with: What would you do to make it a lot simpler?
Disclaimers: provided it's not an actually terrible fit for whatever you're trying to do, or the overhead is enormous, etc.
So, it would have been better for everybody if you chose a boring technology, kept the system running with no hassle and no 3am pages, and spent the quiet evening studying on algorithm questions. But apparently that's not sexy enough.
Perhaps the worst case (but there are so many).. we were 99% java. We hit containerization and a team member hard sells introducing a container that did a relatively small job but was written in Go instead of Java/Python/whatever that is already present.
Team member literally resigns to go work at a Go-Centric job the day they got the merge request approved. I heard about the resignation IN the code review meeting.
Luckily it is/was a tiny thing that hasn't needed much maintenance.
One of the funny things about this being about the "cool kids" doing stuff is the people doing the following were often viewed as the "cool kids" but could only stay that way for a certain amount of time until their tech debt from over-engineering everything caught up with them.
> they want to have on their resume
So in other words... we actually are being hyper-rational, it's the people who discard any experience in anything that's > 5 years old that are creating the problem.
It's sad that software engineers do it to each other, because this year's RDD project is next years legacy rewrite.
If people could be mature and thoughtful and select technologies that have a natural sympathy for the domain and problem they are trying to solve, we'd all be a bit happier.
In my mind, you are shirking your duty if you practice RDD.
The worst one is when that engineer shoehorned completely unrelated technology just because it is hip.