[solardev]

I can't speak to St. Louis, but about the tech stack, my personal experience is that the bigger the company (outside of formal tech companies), the older/slower/more bloated the stack. They tend to choose stability and longevity over modernity, so a lot of Oracle, Microsoft, etc., and whatever their people were using ten years ago. It kinda makes sense at their scale. It's not the core of their business, and they don't like change for change's sake.

If you want a more nimble tech stack, small companies are where it's at -- the ones who don't have much to lose, who are often working on greenfield projects and have both the personnel and the lack of legacy baggage to be able to explore more modern stacks. But even then, you're probably just catching them at the start of a cycle, and if they survive 5-10 years, they'll probably be using an old (by then) tech stack.

I will say this: You can have a lot more sway about the stack once you're hired, especially if you're a full employee. I've convinced several companies to modernize their stacks only after working with them for a year or two, doing good work on their old (terrible) stacks, and then showing a demo of how much easier a new stack could be for the people involved. On the other hand, if I go in swinging during an interview and say "your stack sucks, I want to rewrite it right away" they'll never hire me. Makes sense, because I don't know their pain points and workflows yet; I'm not in a position to make that sort of judgment call from the outside.

Just my 2¢.

[cvccvroomvroom]

You're painting with a broad brush a religious view of an idealized tech stack rather than the problem of motivations at different scales that aren't equal or necessary for each.

Large companies reward resume-grade impact, not cleaning up code, because there is literally no value added (that can be claimed) unless code is used or directly saves money. So spending expensive engineering time refactoring code for future hypothetical concerns isn't viewed as achieving anything, even if it sounds good. It's a shitty reality but necessary to collapse the often disconnect between software engineering and business.

Very large companies also have the staff to roll their own custom everything because COTS FOSS just can't scale up or out well enough at a reasonable cost.

By contrast, startups lack standards and working infrastructure, and are often forced to rely on force multipliers such as potentially expensive SaaS services where they own nothing, not even their data. The upside of startup startups is that there's nowhere for average or lazy engineers to hide: everyone must produce and do things in a maintainable manner or face the consequences of poor operations or paying the price of tech debt.

There are no free lunches, religions, or perfect solutions in real-world web ops. There is only minimizing classes of fires and being able to respond to them in a lasting manner in order to move forward.

[solardev]

I think this makes sense, but might be more of an adjacent argument than a counterpoint? What you said rings true especially for large tech companies, but the OP and I were thinking more of large enterprises whose primary focus isn't in tech (like the St. Louis businesses). Sorry if that wasn't made clear, especially in my post.

The difference, I think, is that large non tech companies don't necessarily think that deeply about their tech stacks. The entrenched bureaucracies and existing vendor relationships (with Microsoft or ESRI, for example) seem to have more sway than the merits of any one stack or another.

Nobody should be refactoring code all the time just for the heck if it, but looking at the architecture once in a while can get you generational improvements in performance, security, user and developer experience, etc. But that's a hard sell in a company that looks at tech as just another basic tooling/infra cost, as opposed to a core part of the business.