But then they didn't have the context as to why those tools were chosen and so often they aren't suited. But I've never met anyone in the last 20+ years with thousands of engineers who was doing it for their resume. In fact the best thing for your resume is for the project to be a success anyway.
Maybe, or maybe it's just realistic in a world where common advice is not to stay at any company for more than 2 years.
The common advice and wisdom is actually not to do this.
This is a long thread unto itself, but in an environment where many companies have zero loyalty to their employees and would rather hire more experienced people than train and promote their existing employees who already know the ins and outs of the company...
Job hopping is often the fastest way to more money and more crucially, more responsibility which means more personal growth.
Those days are mostly dead.
While you might pause for fear of burning your bridges by leaving a project in the lurch, staying at a company for over 2-3 years is not the way forward in a career anymore - and that is very much the common advice and wisdom nowadays.
This isn't because young people want to, this is because you tend to get huge jumps in wage jumping between companies, while simultaneously HR seems to be allergic to giving good raises.
Also, we like playing with new toys. Solving the same old problems the same old way we were doing it 20 years ago just isn't sexy.
I have seen this happen before, and when the interests and ambitions of an individual are counterproductive to the direct needs of the company, that can be deeply problematic.
Looking at new tech is way more interesting than doing the same thing you've been doing for 10 years. Its good to have some mechanism in place to vet that since I know I don't trust myself to always make a good choice (and in my opinion I have excellent taste).
The end result is that not only is the routine stuff boring but it's also career-limiting.
I got advice when switching jobs that I had to be my own advocate and nobody was going to do it for you. I think the advice was meant specifically for that company, but I think it applies to most behind the scenes roles.
Similarly, everyone is excited about a new UI while a bad backend can only drive you away. Massive improvements and scaling can only really be measured by new dollars brought in (but that was due to sales and marketing, right?)
I'm probably being a little naive, but if feature work isn't ongoing, I'd expect that guy heroically slugging it out to make incremental progress in stabilizing the thing so that he didn't need to spend all day at a terminal babysitting a computer program.
And even if it is just for the resume, it's smart and understandable. Consider the difference between, "Eh, I evaluated some NoSQL options here and there, but it seemed safer to stick with Postgresql since we didn't have a compelling reason to experiment. Postgresql works fine at the scale of our product and we're very familiar with it," versus, "Yeah, we used Mongo for a project and it was a shit show, switched to DynamoDB which has been solid. The product is still 80% on Postgresql, but we use Cassandra for analytics, and of course we run InfluxDB for Grafana, which we're going to replace with Prometheus for better scalability." These could be two people facing exactly the same serious of engineering choices, with the first guy making the better decision every single time, but the second guy sounds like the kind of curious and hardworking person you'd want to hire, while the first guy sounds maybe... stuck? Counting the days to retirement? Maybe boring SQL guy has saved his company a ton of engineering work that they were then able to invest in product work instead of engineering, but when he and NoSQL dilettante guy are both interviewing at a new company that wants people who are "curious" and "passionate" about "dedicated to learning and growing their skills" and "ready to meet new challenges head-on" he has to be worried about sounding like a dud.
But I've never met anyone in the last 20+ years with thousands of engineers who was doing it for their resume.
It's not something you can distinguish from being eager to learn and overenthusiastic about new tech, which we all are to some extent.
I don't find it insulting at all. Reality is that many, if not most, recruiters are looking for candidates that have experience in whatever technologies are hot at the time. Expertise in a sought after technology can be worth tens of thousands of dollars extra in annual compensation. It's natural that some people will try to use that technology to further their career if possible. And I think to a degree, a lot of people base their job decisions on what they'll get to work on. 'Is it a stack that is in demand and growing?' 'Is it a stack that might be difficult to learn but pays really well?'
Now the sensible thing to do is to not shoehorn in some tech if it doesn't make sense for a given application. And beyond that, the a big reason people are tempted to chase the shiny new object is because the IT recruiting process is broken.
I just see it as people trying to do the best they can for their career, usually there's no malice involved.
Asking questions is not assuming. I think you're letting yourself be triggered by a flippant remark at the end of an otherwise solid comment.
This is not a real criteria for choosing anything. You can say the exact same thing about ASP.NET WebForms, MySQL, MSMQ or pretty much anything that was popular at any point in time. If you're only looking for "success" stories, you're not doing due diligence as an engineer. Who defines "success" anyway? The same person who chose React, Spark and Kafka in the first place and whose salary is directly proportional to how hyped-up those technologies currently are?
Uh? That's just the norm. I've met very, very few people who actually think about introducing a shiny new technology as a last resort. Usually it's the complete opposite, they start with the shiny new thing they've read about and build systems and even features around it. I've often heard the CV mentioned explicitly as a reason, but there is also a lack of imagination- they just can't think of ways to adapt the current system to their requirements.
Ah, as for the project to be a success... "I've started as the lead developer in a team of two, and after X years the project has grown and I was leading a team of 20"- this is a common success story. Nobody cares about the fact that the team of 20 was needed because the tech choices made were so poor you needed to explode the size of the team.
Keeps me sharp and gives me an opportunity to explore tech that isn't in my day-to-day wheelhouse.
If you are still running on Tomcat, all the best getting the market standard genius talent to work for you.
You would also like to learn about what happens to workplaces where smart people don't work or even like to work at.
Often there's an aspiration to reach Google-level operation. Invariably some director/VP insists on building for that future. Then it turns out sales can't break into the market and adoption is low.
Now you have a neglected minimum viable product because you're scaling that skeleton instead of adding features your existing customers want. Or you're delivering those features at a slow pace because you're integrating them into two versions of the software: the working one and the castle-in-the-sky one. Then there are all sorts of other things that throw a monkey wrench into your barely moving gears: new regulations, competitors nipping at your heels, pivots, demands from management for "transparency and visibility" into why it's taking you forever to deliver their desired magnum opus.
Products that reach Google scale probably get there without even noticing it because they're correctly iterating for the marginal growth.
More importantly, the world changes and software has to change with it. An accounting system will need to be fitted to changing regulatory frameworks in the future. That knowledge is the basis of good application design. Schemaamnesia databases with highly-scalable vendor-locked PaaS peripherals that are constantly changing also require constant developer attention, but do not rise to that challenge.
A technology that's been around for decades and is still considered a viable candidate will be much more reliable, documented, mature, bugfree... than some new library that is untested hasn't been worn smooth over time.