100%
My company is in the process of switching from niche language to Python.
The problem is that niche language was a good proxy for "people who have been in the industry / have a lot of domain knowledge / etc".
So our hit rate with the Python dev interviews is like 1/10th of what we had with "niche language" so yes mainstream devs are easier to find, but they are 10x as hard to filter. Further the original excuse was that niche language devs were expensive, but by the time we find a python dev who actually has any domain knowledge & experience, we are paying the same.
Would it be feasible to lower the hiring bar and set things up so that your company can use some of those plentiful, less experienced, less expensive developers to do some of the straightforward gruntwork that comes with any project? I suppose that's harder to do with Python than it would be with a statically typed mainstream language like Go or Java, since a static type system provides another way of guarding against mistakes. But maybe Python with enforced type annotations as part of the CI process would be good enough.
Sure and in a way we ended up doing some of that bar-lowering.
However we could have done the same on the old niche stack which is what I used to do elsewhere. Instead of generic python devs 2-3 years out of school with 0 domain knowledge getting 50% more than starting grad salary.. you just hire new grads, teach them the niche tech & domain knowledge at once. Plus side is they are trained in "your way" and there's less retraining.
But either way, grunts depend on the lifecycle of the product.
You bring in grunts to run the plant once you've built it.
When you are in the process of building the plant you have a lot of dev work you want experienced (domain & tech) seniors doing. Foundational decisions and implementations that come from having some scar tissue in the tech & domain. Throwing grunts at the problem early will just allow you to re-implement your previous mistakes in similar ways.
And yes Python doesn't feel like a great system building language, it will probably be tucked away into the same corner as Perl in a decade or so.
My hypothesis is that not all tasks in a software project require the same level of skill or domain expertise. Context: I'm the technical cofounder and (currently) sole developer of a tiny company developing SaaS applications. The core of these applications definitely does require my domain expertise. But other things, like the purchase UI and account administration, just require one or more programmers with adequate skill and a strong, reliable work ethic to deliver (and maintain!) good enough implementations. Perhaps this suggests a two-language approach for such applications, with the domain-specific core being written in a more niche language. But polyglot projects bring their own complexity that makes it harder to eventually hand off maintenance.
A lot of the "lets just hire lots of grunts" mentality implies someone is going to do a lot of the other work - talking to users, documenting requirements, creating well specified dev tickets, implement SDLC tooling, integrate with SRE, create guard rails, do documentation, testing, code reviews, style guides, etc.
Which is to say - most of the stuff you expect a senior to just be able to do as part of their job while also writing better code.
A large enough org may be able to offload much of those tasks to dedicated people and/or teams. Similarly a mature enough platform could have lots of BAU dev that can go to grunts because the basic infrastructure already exists and the workflows are well known with good tooling.
So it really depends on organizational size & maturity if its a good trade.
Funny you should mention that - I remember when younger that we measured my younger brother at two, and he grew up to hit the predicted height, reaching 6'9". Played basketball professionally. When he outgrew me as a teenager, my only chance in one-on-one was to play rougher and call no fouls. My dunks were on the school outdoor court with a slightly bent-down ring!
It's not clear that writing tooling in Javascript has been a win.
I do hope that we can get back to that "JS as compilation target" model eventually with WebAssembly. Even with improvements like TypeScript slathered on top, it's not fun writing Javascript, the tooling sucks, and it's vastly less productive than better developer ecosystems.
Dishwasher soap in the US is garbage now, so you have to scrub anything that might possibly stick on, despite the wash cycle on my dishwasher taking nearly two and a half hours.
The tabs I use are environmental friendly. I.e. no phosphates, no palm oil, no chlorine. The wrapper dissolves in the machine (an algae-based polymer similar to what is used for capsules to deliver meds).
I live in the US, never pre rinse, used cascade platinum or some homemade mix of washing soda and essential oils I received as a gift, both work great, dishes are very clean in the machine.
This is what I did for years before March 2020. Maybe I'll go in once in a while to get out of the house, but maintaining two development workstations is a drag.
Unless there's an office pizza party or a real scheduled brainstorming session, it's not worth physically being there.
And vim in particular: free, vast availability, no GUI needed, regex, macros, plugins, folds, block editing, syntax highlighting, drop in your vimrc and go, runs shell commands, etc.
