Incidentally, this job-hopping is bad for software, because too much institutional knowledge is getting lost, and the job-hoppers don’t get to experience the long-term consequences of their design and implementation decisions.
It can be good for software too. Best practices and new ways of working slowly dissolve through other companies as employees move around. Many of the great technologies invented at the FAANGs eventually get recreated at other companies or in open source because of this movement.
> Best practices and new ways of working slowly dissolve through other companies as employees move around.
Doesn't help against cargo culting and reinventing wheels Just Because We Can And Have The Money.
Just because Google did Kubernetes everyone else followed suit despite there being competitors available (e.g. DCOS, but that one sadly failed because it was utter bananaware). Everyone followed Google for Angular and then went over to Facebook's React, and on the backend side it's Go here and Rust there.
All of those were made to solve problems with their predecessors and I believe that almost every one of them (Angular is debatable) has been a success in moving the needle.
> All of those were made to solve problems with their predecessors
This is not really a question, yes. But... they're sledgehammers and most of the people used them because "the large ones are doing it" - for a loooot of use cases simpler solutions such as plain old jQuery+SCSS / Portainer or Docker Swarm/Compose would have been more than enough.
I have worked with both DCOS and Kubernetes - the latter is way more coordinated and polished, with also better fundamentals underneath.
This results in a situation where a lot of different places have logical, reasonable reasons to pick k8s because it matches reasonably well 80% of their needs, and while everyone's 80% is different, there's enough overlap. This pulls in, like frame dragging, others who might not actually need it, but it's not because some scaling memes.
In practice, a lot of initial intake for k8s was not bananas scaling arguments, but it actually solving problems for people who either had growing complex messes, or considered the spend associated with "good practices" that are often thrown as argument against kubernetes, like running separate cloud instances for every application.
Similarly, everytime I look at Nomad and related stack, it turns out that various bits are missing, and DIY will be harder than with k8s-like stack because it's not properly designed to be extensible.
Having good documentation is great, but there is nevertheless a substantive cost in high turnover even if you have good documentation. Documentation doesn’t replace experience with the product or project, nor is it ever complete.
Looking back at my own career, I do not jump ship every 18 months, and I have been able to accumulate deep knowledge that are broadly applicable, that has enabled a lot of options when it is time to go to a new company.
So in addition to having better continuity of institutional knowledge, there is a benefit to staying on longer (at least for me).
I've seen former coworkers brag on their CVs about "highlights" for work they did that was nothing short of an unmitigated disaster. But they didn't stay long enough to watch the meltdown.
Middle-upper management also excels at this method of escaping blame/consequences. Move in, talk big and change a bunch of stuff, then on to the next before the tickets start coming in.
