Having spent from teens till 50's in tech I offer my insight. When I started out, I was all trained up in cutting edge and to walk into a job that did not do t

Having spent from teens till 50's in tech I offer my insight. When I started out, I was all trained up in cutting edge and to walk into a job that did not do that. I learned why. 1) Bleeding edge tech is just that, something will bleed. 2) Skill debt 3) Standards Those are the main three. 1) Bleeding edge - all software has bugs, anything new needs time to mature and when your running a business and want your nth 9's uptime, stability, robustness.....just works and does the job at hand - everything that something less mature, tried and trusted offers. Sure it may be that rare - just works from day one, but the odds are terrible when most often it will not. 2) New skills will be needed and paradigm shifts just never happen, it's costly and transitions are gradual and glacial almost. You also have legacy stuff that needs support. I've worked at companies doing paradim shifts, ended up leaving existing employees stuck supporting the old and they got new staff in to play with the new toys. This saw the buisness knowledge in the old team ignored and also saw many leave as the new team was, well, arragant and in the end, the old system lost traction and the new system never ever worked as well as the old system due to lots of bleeding edge gotcha you would never expect, like many bugs. But that was the days of 4Gl's in the late 80's. We still have COBOL today for many reasons - it just works and does the job at hand and has proven to do that for a long time. "Trust is earned, never given away" Klingon proverb that is true for IT in the business world. 3) Standards - this ties up with the previous two, but equally is important as you need to have standards and anything new takes time to curate those standards, in coding and operation, these nuances take time to perfect and equally are important if you want to start out right with any tech in business that depends upon such tech. Standards, whilst operation and some best practices will be common for all, but each buisness will haev it's own nuances and that plays out in standards. Be that naming convention. Though you can and I have seen odd standards that had a passing back to the legacy code/system and that was due to making things logical across those systems and that would be mostly in naming standards, data formats, many things that all add up. But yes, it's nice to play with new bleeding edge toys, but for many businesses - that will not be what they want. They prefer toys which have seen every possible accident happen and all safety revisions are in place and it is now stable without updates every other day. But for some businesses - being able to run with cutting edge is their business, or case of the new project in which the risk is offset by the gains more easily and everybody has their own segway...