Microservices were a mistake. I should have fixed the underlying problem with the DB (we were misusing the ORM) first. It's fixed now, but we still have to deal with debugging microservices which sometimes mysteriously fail.
There's a whole bunch of other cruft I sprinkled throughout the codebase. Good news is I left with good experience, because I made a few mistakes. Bad news is they still have that architecture.
That's why you always need a senior developer on deck to tell young whippersnappers like me "no" every so often.
Increasingly, I'm understanding the benefit of working on projects outside of work -- so you can make mistakes like that on your own time. I wish more people followed the Google model and gave you every Friday to mess around with your own projects.
20% projects are still technically a thing, but not many engineers actually have one.
It only took them 10 years to fix the header file mess.
Sure, if your interests are closely aligned with the company. But as you noted, the junior engineer jumped ships 3 times already, probably with significant salary increase each time, and in part due to a CV that includes the use of exciting modern tech, which shows he's eager to learn and is passionate etc. Why would he care how the old company is doing?
People often don't stay at the same place long enough to feel the long-term consequences.
People will do whatever the (job) market rewards and is fun.
It's a bit different when you wear multiple hats. Then it may be best to focus on one specialization and keep things boring for the rest. For example at a small company, as a single-person data scientist/engineer/developer you may want to focus less on the IT fads and more on the modeling, because your CV is best padded by fancy new ML models, not by fancy new database engines. Or vice versa.
Because at one point one recruiter or HR manager will ask him to provide a reference from his previous manager? And when he looks like an absolute ass he can pad his resume with whatever he wants? Short time thinking will not get rewards in the long run in that case.
The reason we have this phenomenon is that companies highly value (or even overvalue) experience with hot new technologies. So even if as a developer you know that maybe kubernetes, microservices, and NoSQL [or whatever it is] are not right for your organization, you know that having those on your resume will help you get a big raise and a promotion on the next job. The chances that your new tech chasing misadventures will haunt you in future jobs is very low.
But there's no reason you can't work a day-job doing boring technology and do fun stuff on your side projects.
Companies should actively support your side-projects, especially if they involve R&D experimentation that could be useful in the long run to the company. Whether that's paying for you to attend educational events or any books/online video courses/supporting SaaS services/etc or giving you 10-20% of your week to do what you want.
The foremost role of senior devs (at least in a company with juniors and mid-levels) should be technical oversight. Set up the architecture, set standards, and do the code reviews.
Not sit in the corner and learn React.js.
I was talking about junior devs making (predictable) bad choices not senior devs. Your senior developer should know better than to shiny chase and value delivery over cute technology, otherwise he's not a senior developer.
Some startups can't afford a senior developer or simply don't know any better... but even junior can pump out working apps. Then it's just up to the next evolution round when you build a professional team instead of some cowboys.
Sounds to me like this is an endorsement of hiring less-shiny candidates who have been at their previous employers for longer rather than the shiny candidate who keeps jumping ship every time.
If a team's management can't prevent this from happening, then they've got bigger problems to worry about.
Because everyone has different interest/goal. The interest/goal of junior developer is different than the senior developer, even though both working in the same company.
It might very well be in their best interest for the junior develop to play with shiny toy, if that the case then that is what they should do.
While for the senior developer though it might be in their best interest to prevent that.