The Industrial Hammer Complex(eisenbergeffect.medium.com)
eisenbergeffect.medium.com
The Industrial Hammer Complex
https://eisenbergeffect.medium.com/the-industrial-hammer-complex-d9785886ee59
12 comments
> many devs at big and mid-sized companies have a very clear financial incentive to adopt the latest trends.
I used to be more hesitant about whether it was a good idea to start out with microservices, then I started going on interviews. I would paraphrase the phone screens I was given as "Have you accepted microservices as your Lord and savior?". Call after call they wanted me to extoll the virtues of microservices before even considering me for an interview.
I used to be more hesitant about whether it was a good idea to start out with microservices, then I started going on interviews. I would paraphrase the phone screens I was given as "Have you accepted microservices as your Lord and savior?". Call after call they wanted me to extoll the virtues of microservices before even considering me for an interview.
Interestingly I had the opposite. The more recent interviews I did asked about the advantages and disadvantages of using monoliths vs microserviced, and how to overcome the common problems.
I also had questions asking me how I would write frontend applications with and without central state management, or even for which cases I would start with a reactive frontend framework.
In one of them I even had a huge disagreement with the interviewer. He still made a point to say I had passed.
I think the main difference in this case was that I was interviewed by seasoned pros. When I had interviews with less experienced developers, the topics were as trivial as possible and just looking for confirmation.
I also had questions asking me how I would write frontend applications with and without central state management, or even for which cases I would start with a reactive frontend framework.
In one of them I even had a huge disagreement with the interviewer. He still made a point to say I had passed.
I think the main difference in this case was that I was interviewed by seasoned pros. When I had interviews with less experienced developers, the topics were as trivial as possible and just looking for confirmation.
I guess you and the parent are sampling the microserivce hype curve at different points in time.
I wonder if this incentive is stronger at smaller startups. If I routinely work in small startups which are likely to fail, then spending time in aspects of the stack which are likely to be needed at future startups is a smart use of my time.
Micro-services have fairly extreme upfront deployment/automation overhead relative to monoliths. This setup effort is common across many firms adopting microservices.
Micro-services have fairly extreme upfront deployment/automation overhead relative to monoliths. This setup effort is common across many firms adopting microservices.
I've for sure found myself thinking along those lines in the past. It's definitely possible it's a common enough thought to affect culture as you suggest.
> It would be silly to expect software developers (who are typically intelligent and highly analytical) not to realize that the incentives are very clearly stacked towards following the latest trends. Now I do think that this is a very suboptimal outcome for the company, but if they since they are the ones setting the incentive structure in the first place it is difficult to feel too sorry for them.
Incentives matter, if you learn nothing else about economics learn this. People do things that they feel are best for them so companies need to align personal incentives with company outcomes or face sub-optimal solutions for the companies because the employees feel the solutions is optimal for themselves.
With an average employee tenure at a company being a few years, how can longer term issues with software ever be a deciding factor for employees.
Incentives matter, if you learn nothing else about economics learn this. People do things that they feel are best for them so companies need to align personal incentives with company outcomes or face sub-optimal solutions for the companies because the employees feel the solutions is optimal for themselves.
With an average employee tenure at a company being a few years, how can longer term issues with software ever be a deciding factor for employees.
He didn't touch on the fact that the tech is predetermined by the hype. Most of us just have to work with whatever the CTO likes right now or whatever the team thinks is the "most modern."
I am jealous of your problems. Many of us have to work with the best obsolete tech that is still compatible with even more obsolete tech.
This doesn't even just apply to developers. The same is true for managers, all levels of HR, ...
His take on React as some kind of marketing-driven conspiracy just seems odd to me.
React became popular because it solved problems that everyone in the frontend was having, did so in a way we could understand, and it did this so well that we were willing to put up with shortcomings like being forced into a SPA, CSS-in-JS, etc. We could jump in with just a little corner of our site or go all-in to a robust ecosystem that was continually evolving to meet the needs of the modern Web, and the resulting code was far more likely to be understood by a new employee than the bespoke jQuery soup that we replaced.
And critically, this was all free and open source. No lifetime hammer subscriptions involved. No lock-in, no monetary sunk costs, so why not try it out?
> I was deeply connected into the valley culture, watching what was happening from the Google side when it all started. It wasn’t money Facebook was looking for, it was talent and mindshare (i.e., power and control).
...Okay? But I'm guessing that most people who adopted and use React on a regular basis have zero interaction with Facebook or Google (the companies that is, not the product).
I dunno. Seems like the critique is a hammer looking for a nail.
I get the concerns about using React in places it doesn't need to be used, and I'm glad that the ecosystem has matured and innovated to allow us to keep what's great about React while also getting back SSR (though there's still work to be done here) and figuring out the best ways to work regular CSS into it.
React became popular because it solved problems that everyone in the frontend was having, did so in a way we could understand, and it did this so well that we were willing to put up with shortcomings like being forced into a SPA, CSS-in-JS, etc. We could jump in with just a little corner of our site or go all-in to a robust ecosystem that was continually evolving to meet the needs of the modern Web, and the resulting code was far more likely to be understood by a new employee than the bespoke jQuery soup that we replaced.
And critically, this was all free and open source. No lifetime hammer subscriptions involved. No lock-in, no monetary sunk costs, so why not try it out?
> I was deeply connected into the valley culture, watching what was happening from the Google side when it all started. It wasn’t money Facebook was looking for, it was talent and mindshare (i.e., power and control).
...Okay? But I'm guessing that most people who adopted and use React on a regular basis have zero interaction with Facebook or Google (the companies that is, not the product).
I dunno. Seems like the critique is a hammer looking for a nail.
I get the concerns about using React in places it doesn't need to be used, and I'm glad that the ecosystem has matured and innovated to allow us to keep what's great about React while also getting back SSR (though there's still work to be done here) and figuring out the best ways to work regular CSS into it.
> His take on React as some kind of marketing-driven conspiracy just seems odd to me.
To me it's so out of reality that it tainted his whole article
Granted I'm not in the US tech scene, but I chose React because AngularJS was horrible (it took one project to never again touch it) and Backbone was arcane and confusing, and I really clicked with JSX
To me it's so out of reality that it tainted his whole article
Granted I'm not in the US tech scene, but I chose React because AngularJS was horrible (it took one project to never again touch it) and Backbone was arcane and confusing, and I really clicked with JSX
I agree. I had to double take on this. I think the difference is that react is really an abstraction, unlike micro services. It would be kind of like accusing Bell Labs of making C or Unix as some sort of conspiracy — if you don’t write your own bootloader you’re someone with a hammer complex?
I was sort of expecting him to go after SSR mania, which would make a lot more sense to me (I am guilty of of this). But railing on an abstraction pattern that literally brought JavaScript out of the dark ages seems way off.
I have noticed in myself and other developers with a decade plus that there is new tech fatigue eventually. With enough cynicism it can look like everyone is trying to use their new hammers on everything (sometimes they are). But I think that’s the flip side to this article and I’m glad he made the React point because it really elucidates the whole thing. Everyone looks like they have a hammer complex when you aren’t interested in learning new things. I think there’s so much value in experience and until he got to React, my internal dialogue was shouting “amen” after every sentence but it’s painfully clear the author did not want to engage or think about the problems React solved.
I was sort of expecting him to go after SSR mania, which would make a lot more sense to me (I am guilty of of this). But railing on an abstraction pattern that literally brought JavaScript out of the dark ages seems way off.
I have noticed in myself and other developers with a decade plus that there is new tech fatigue eventually. With enough cynicism it can look like everyone is trying to use their new hammers on everything (sometimes they are). But I think that’s the flip side to this article and I’m glad he made the React point because it really elucidates the whole thing. Everyone looks like they have a hammer complex when you aren’t interested in learning new things. I think there’s so much value in experience and until he got to React, my internal dialogue was shouting “amen” after every sentence but it’s painfully clear the author did not want to engage or think about the problems React solved.
Yeah. Pick your analogy:
- React is the iPhone of the frontend library world. Not the first, some will never say it's the best, but it put things together in a way that resonated with people and organically conquered a ton of mindshare.
- React is the Model T. Before the Model T there was a massively fragmented landscape full of mechanical wizardry and bespoke manufacturing. After the Model T the industry was larger, more consolidated, and standardized.
I don't believe that React will dominate forever. But I do believe that, 50 years from now, people talking about the history of the frontend will view React as the defining thing from the era we're in now.
- React is the iPhone of the frontend library world. Not the first, some will never say it's the best, but it put things together in a way that resonated with people and organically conquered a ton of mindshare.
- React is the Model T. Before the Model T there was a massively fragmented landscape full of mechanical wizardry and bespoke manufacturing. After the Model T the industry was larger, more consolidated, and standardized.
I don't believe that React will dominate forever. But I do believe that, 50 years from now, people talking about the history of the frontend will view React as the defining thing from the era we're in now.
I think a better analogy would be to compare React frameworks to the iPhone, everything works nicely and a lot of choices have been made for you.
React itself is just a really good JS library, not a full opinionated framework. I made the choice to use React because it was possible to add individual interactive components to an ASP.NET Razor MPA without rewriting the whole thing. Gradually React takes over more and more functionality, necessitating a need for a framework, and then we get the iPhone experience.
React itself is just a really good JS library, not a full opinionated framework. I made the choice to use React because it was possible to add individual interactive components to an ASP.NET Razor MPA without rewriting the whole thing. Gradually React takes over more and more functionality, necessitating a need for a framework, and then we get the iPhone experience.
Yeah, how would Facebook secure talent for itself on the basis of React if everyone else is also using React? Twitter started using React very early on, and Twitter is one of Facebook's biggest social media rivals. Facebook also made no money from React. They developed it because it solved problems for them internally on a complex code base. I've also never seen the original team (Jordan Walke / Pete Hunt) hit the paid course or YouTube influencer circuit. Angular on the other hand, was barely used internally within Google. Most Google products at the time used Closure, their heavy handed JS tooling system (with its custom compiler): https://developers.google.com/closure/library
Maybe its just my bubble but somehow I seem to encounter far more commentary railing against these sorts of trends than actually genuinely promoting them, nevermind people claiming them as silver bullets. As such I can't really empathize with statements like:
> I wish I could say this was merely the problem our industry has, but it’s far worse than this. What we actually have is an industrial complex bent on manufacturing only hammers, committed to convincing you that only nails exist, and motivated to sell you a lifetime hammer subscription
> I wish I could say this was merely the problem our industry has, but it’s far worse than this. What we actually have is an industrial complex bent on manufacturing only hammers, committed to convincing you that only nails exist, and motivated to sell you a lifetime hammer subscription
Microservices are definitely on the way down, but make any comment here or in a startup in the vein of "You don't need AWS/the cloud" and you'll see what's the real zeitgeist.
SPAs also get a lot of criticism here at Hacker News, but talk to a team of frontend developers and you'll get puzzled looks for suggesting rendering HTML directly in your C# or Rails monolith.
Please notice that I'm not criticizing or advocating anything, I'm just saying that there are trends and they're strong to the point of almost becoming laws. IMO this is what the article criticizes.
SPAs also get a lot of criticism here at Hacker News, but talk to a team of frontend developers and you'll get puzzled looks for suggesting rendering HTML directly in your C# or Rails monolith.
Please notice that I'm not criticizing or advocating anything, I'm just saying that there are trends and they're strong to the point of almost becoming laws. IMO this is what the article criticizes.
SPAs get flak because some people have strong opinions on what a website should be, completely ignoring that many if not most software companies make client-server applications where the browser just happens to be the software distribution method, and none of the big web ideas matter. SPAs fit right into what already was there in the form of desktop clients. In that space, MPAs were a trend borne out of the limitations of the browser, but there is no reason to go back now.
SPAs get flak because they’re being used incorrectly.
If they truly were only used as desktop-based apps, there would be less to complain about. As it stands, they’re packaged incorrectly for the mobile devices people use, caching is an afterthought so we’re loading the same giant bundles across mobile networks on each load, and this affects apparent performance. Then we have too much animation or inefficient component refreshing that reduces responsiveness…
If they truly were only used as desktop-based apps, there would be less to complain about. As it stands, they’re packaged incorrectly for the mobile devices people use, caching is an afterthought so we’re loading the same giant bundles across mobile networks on each load, and this affects apparent performance. Then we have too much animation or inefficient component refreshing that reduces responsiveness…
Sure, if people always went the extra mile to provide the best experience, things would be better, but that has nothing to do with SPA versus MPA. Some things by default are cheaper with SPAs, some with MPAs, so the default annoyances are different - but neither gives a great experience for free.
Yes, for example drawio.com is an application that happens to have a version that runs on the web (not affiliated, but use it a lot). That's a very different situation from e.g. developer.mozilla.org, which is more text-centric and where being able to send someone a link to a particular section on a particular page is extremely useful.
SPAs are useful where needed. When overused they get the deserved criticisms, just like microservices or any other technology that becomes widely used beyond their scope.
SPAs are also useful even where they aren't strictly needed, which upsets the purists. Once you have decided that you orient your teams around SPA architecture, going the extra mile for whenever an MPA might do things better (by some metric) becomes a tough sell. The things that web developers believe should matter to users don't necessarily matter to the business as a whole. This is another instance of "worse is better".
I understand the SPA team argument but keep in mind how much complexity SPAs add to projects and how much more resources those teams eat. As a dev I'm okay with this as this enables more work for us devs but having done work with simpler technologies that were easier to maintain, were simpler and so on I can't shake the feeling of wastefulness SPAs give me.
> Once you have decided that you orient your teams around SPA architecture, going the extra mile for whenever an MPA might do things better (by some metric) becomes a tough sell.
Another aspect is here is that if you have people split up (more or less strictly) in backend and frontend devs, then SPA kinda follows naturally
Another aspect is here is that if you have people split up (more or less strictly) in backend and frontend devs, then SPA kinda follows naturally
Yep, I've been nearly cussed out for suggesting the code won't always be run on Lambdas. Nope, AWS Lambda is end-all be-all of code execution.
I think the commentary railing against these sorts of trends talks about them in general, whereas the commentary promoting them talks about solving particular problems. So if you ask "how to fix foo bar issue with my system design" you might get people suggesting how to solve it with one of these "hammers" instead of a broader condemnation of overuse.
This just in, a mans opinion is that others opinions are all made up!
All kidding aside, life is full of choices just like programming is. It's also full of, at times, cascading tradeoffs. Following popular patterns isn't new to technical fields, even if they can have sharp corner cases. When your income is dependent on delivery then you'll often side with whatever presents a high-confidence score in terms of success.
There are also very few definitely right decisions to make in software architecture and much more definitely wrong ones. How many times have you heard, "I shouldn't have used x full stack framework because I wanted to do y" or "I shouldn't have written x from the ground up because I could've used y". Many of these decisions you can only fully know what category they fit into after the deed is done.
A lot of this derives from the fact that most of these things are learned on the job. There is no course you can take that will succinctly teach you to migrate a hulking, interconnected monolith to microservices or vice versa. You just have to have been the sad sap who's done it before and have enough knowledge of the standards and innards involved.
What I take some umbrage with is just labeling everyone snake oil salesmen.
All kidding aside, life is full of choices just like programming is. It's also full of, at times, cascading tradeoffs. Following popular patterns isn't new to technical fields, even if they can have sharp corner cases. When your income is dependent on delivery then you'll often side with whatever presents a high-confidence score in terms of success.
There are also very few definitely right decisions to make in software architecture and much more definitely wrong ones. How many times have you heard, "I shouldn't have used x full stack framework because I wanted to do y" or "I shouldn't have written x from the ground up because I could've used y". Many of these decisions you can only fully know what category they fit into after the deed is done.
A lot of this derives from the fact that most of these things are learned on the job. There is no course you can take that will succinctly teach you to migrate a hulking, interconnected monolith to microservices or vice versa. You just have to have been the sad sap who's done it before and have enough knowledge of the standards and innards involved.
What I take some umbrage with is just labeling everyone snake oil salesmen.
I think there was a point where the default was microservices+massive cloud infrastructure and it was a massive disservice to everyone. Everyone 'built to scale' and it's also easy to assume your next project will service a few thousand requests per second eventually and you'd love to just change the replica count in k8 instead of take the day to spin up some new machines and balance them when that time comes.
I've always thought of the practice of salespeople selling software that "does everything" and "makes everything visible to management" as selling the metaprogram.
The metaprogram is an all in one piece of software (or hardware) that replaces all of IT with a system that is easily understood and controlled by management, is relatively inexpensive, easily expandable to new purposes, and solves whatever problems the target company seems to be having at the time.
I've seen IT department middle managers and CIOs try to do this over and over again. When a good solution to a problem is presented that's practical, affordable, and effective, their very next thought is "but what if it also did XXXX". I guess that's how they "add value" or something, by suggesting ideas that have already been discarded for reasons of scope, funding, or time.
So far in my career I've seen salespeople use the idea of solving any pain points for the target company including reducing costs and increasing reliability by selling:
* Desktop Microcomputers
* Peer to peer networking
* Dedicated internet lines (when they were still phone company lines)
* Minicomputers (transition from Mainframes)
* Java machines everywhere
* Clustering software and hardware
* Physical and virtual partitioning of systems
* Thin Clients
* Cloud everything
* Containerized data centers
...and there are many more. I find it's mostly sales people and middle managers that benefit from the hype cycle. As with any new technology in any industry, things become part of the tool box. The main reason a lot of modernization projects get launched is the same reason that business re-orgs happen - they're a way for managers with no other ideas to show they're contributing.
The metaprogram is an all in one piece of software (or hardware) that replaces all of IT with a system that is easily understood and controlled by management, is relatively inexpensive, easily expandable to new purposes, and solves whatever problems the target company seems to be having at the time.
I've seen IT department middle managers and CIOs try to do this over and over again. When a good solution to a problem is presented that's practical, affordable, and effective, their very next thought is "but what if it also did XXXX". I guess that's how they "add value" or something, by suggesting ideas that have already been discarded for reasons of scope, funding, or time.
So far in my career I've seen salespeople use the idea of solving any pain points for the target company including reducing costs and increasing reliability by selling:
* Desktop Microcomputers
* Peer to peer networking
* Dedicated internet lines (when they were still phone company lines)
* Minicomputers (transition from Mainframes)
* Java machines everywhere
* Clustering software and hardware
* Physical and virtual partitioning of systems
* Thin Clients
* Cloud everything
* Containerized data centers
...and there are many more. I find it's mostly sales people and middle managers that benefit from the hype cycle. As with any new technology in any industry, things become part of the tool box. The main reason a lot of modernization projects get launched is the same reason that business re-orgs happen - they're a way for managers with no other ideas to show they're contributing.
The most important sentence in this article:
"Remember that you are a problem solver before you are a technologist."
(Almost) everything we make has users. The most important criterion we have for deciding how to build things is "will it make life better for our users?"
"Remember that you are a problem solver before you are a technologist."
(Almost) everything we make has users. The most important criterion we have for deciding how to build things is "will it make life better for our users?"
It took sooo much arguing on my part with the others on the frontend team about exactly this.
“We can improve email validation on the client by shipping a TLD list with the other logic …”
To what end? How does the additional complexity help the user? They can fat-finger any part of their email address and we can’t validate whether the user name should contain a g or h. Who’s going to maintain the list? So rather that listen to reason little ol’ me, we had to set up a meeting involving The Architect …
He made the call that the complexity wasn’t worth the effort, that the UX wouldn’t be improved, and we shouldn’t add TLD validation in the client. That’s when they finally dropped the idea.
“We can improve email validation on the client by shipping a TLD list with the other logic …”
To what end? How does the additional complexity help the user? They can fat-finger any part of their email address and we can’t validate whether the user name should contain a g or h. Who’s going to maintain the list? So rather that listen to reason little ol’ me, we had to set up a meeting involving The Architect …
He made the call that the complexity wasn’t worth the effort, that the UX wouldn’t be improved, and we shouldn’t add TLD validation in the client. That’s when they finally dropped the idea.
ugh. I'm going to guess this guy never worked on a microservice project in earnest.
I work on two large cloud products. One is a monolith, one is microservice-based.
The microservices and the connections between them are easier to reason about than the free-for-all connections and dependencies between components in the monolith.
We have a far easier time adding new features to the microservice product. And somehow, the microservice produce requires less maintenance and is far more reliable than the monolith.
I could go on and on, but then I'd have more own blog article
I work on two large cloud products. One is a monolith, one is microservice-based.
The microservices and the connections between them are easier to reason about than the free-for-all connections and dependencies between components in the monolith.
We have a far easier time adding new features to the microservice product. And somehow, the microservice produce requires less maintenance and is far more reliable than the monolith.
I could go on and on, but then I'd have more own blog article
I was hoping this was going to be about this kind of industrial hammer.
https://www.tmj4.com/news/milwaukee-tonight/exploring-one-of...
https://www.tmj4.com/news/milwaukee-tonight/exploring-one-of...
> When Facebook introduced React, that act transformed the font-end space into a hype-driven, cult-of-personality disaster zone where folks could profit from creating the right image and narrative
The author must have barely been paying attention to JS scene pre-React. The churn of tooling from 2010-2015 was far worse than anything since. A large part of this was due to the shortcomings of pre-ES2015 JavaScript itself.
ES5 JS had no module system. It had no package manager. Even if you used server-side rendered PHP, Ruby, Java, or C# (the default in those days), JavaScript ended up becoming a massive part of any code base. What started as a few JQuery selectors adding dynamic/interactive behavior to forms would quickly evolve into an unmanaged mess of tens to hundreds of thousands of lines of code. I worked for an enterprise shop that pitched itself as a C# .NET stack, but when you analyzed the ten year old code base, we had more lines of JS than C#.
When every page imported its own version of JQuery or some plug-in, even updating a package across your code base would turn into a hot mess (and might unpredictably break things, as each page independently managed its own dependencies, often imported from some CDN somewhere).
The desire to build a SPA was rooted in the fact that none of these server-side languages had a good native way of managing JS. It was always treated as some afterthought that was injected into some god awful HTML template somewhere.
The JS ecosystem had to create these tools, and there were lots of attempts at wrangling various parts of the architecture from Backbone, Ember, Grunt, Gulp, Bower, Knockout, Flight, Eve, Angular, Dojo, Closure, Ext JS, Moo Tools, etc (and more that I've forgotten) all pre-dating React.
The author must have barely been paying attention to JS scene pre-React. The churn of tooling from 2010-2015 was far worse than anything since. A large part of this was due to the shortcomings of pre-ES2015 JavaScript itself.
ES5 JS had no module system. It had no package manager. Even if you used server-side rendered PHP, Ruby, Java, or C# (the default in those days), JavaScript ended up becoming a massive part of any code base. What started as a few JQuery selectors adding dynamic/interactive behavior to forms would quickly evolve into an unmanaged mess of tens to hundreds of thousands of lines of code. I worked for an enterprise shop that pitched itself as a C# .NET stack, but when you analyzed the ten year old code base, we had more lines of JS than C#.
When every page imported its own version of JQuery or some plug-in, even updating a package across your code base would turn into a hot mess (and might unpredictably break things, as each page independently managed its own dependencies, often imported from some CDN somewhere).
The desire to build a SPA was rooted in the fact that none of these server-side languages had a good native way of managing JS. It was always treated as some afterthought that was injected into some god awful HTML template somewhere.
The JS ecosystem had to create these tools, and there were lots of attempts at wrangling various parts of the architecture from Backbone, Ember, Grunt, Gulp, Bower, Knockout, Flight, Eve, Angular, Dojo, Closure, Ext JS, Moo Tools, etc (and more that I've forgotten) all pre-dating React.
Oh. He is well aware. He created a JS framework called Aurelia. It is actually very good and was doing 'just write js' long before svelte came along. It is not that popular and hence lack the ecosystem.
I vaguely remember Aurelia. Didn't catch the author's name when I first read it. I used Durandal back in the day (which was a sort of Angular-like framework built on KnockoutJS), which he also created, before deprecating for Aurelia. So the author was one of the primary contributors to early 2010s JS framework churn and bemoans React "winning", I guess. Either way, after writing JSX components, I'm never going back to a proprietary HTML template syntax.
good observations and I'm in general agreement, sifting the genuinely novel from fish and chip wrapping is an evergreen activity, the article was a bit long though, maybe break it up into smaller chunks?
You could make it a tweet stream! Its such a great format for when your entire thought thesis doesn't fit in 288 characters. /sarcasm
i was thinking tiktok ;)
tldr of article; engineering is about trade offs. As humans we are susceptible to hype cycles and financial influences. Now let me tell you about a bunch of things I have personally decided are not worth considering the trade offs of under any circumstance.
I don't like how this paints devs as blind followers without any opinion or agenda of their own. From my perspective many devs at big and mid-sized companies have a very clear financial incentive to adopt the latest trends.
The way an IC increases their income is usually either by being promoted or by job-hopping to another job with better pay. Getting promoted past a certain point is all about impressing your boss (or promotion committee in certain companies) and "developed a new architecture based on latest insights" is just inherently more impressive than "kept the decade old monolith online for another year". Similarly for job-hopping, hiring managers empirically seem more interested in people with modern tech stacks on their CV than in people who seemingly haven't learned anything in the last 15 years. Thus, devs have a strong incentive to learn and adopt new tech stacks and doing so during work time is clearly the most efficient way to do that.
The jumps in pay between various levels (junior/senior/lead/principal/etc) can be incredibly significant. It would be silly to expect software developers (who are typically intelligent and highly analytical) not to realize that the incentives are very clearly stacked towards following the latest trends. Now I do think that this is a very suboptimal outcome for the company, but if they since they are the ones setting the incentive structure in the first place it is difficult to feel too sorry for them.