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.

No, this is just not how developing software works.

Throwing more lower-skilled people at a project just makes it move slower and reduces quality.

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.

That sounds reasonable, but the requirements you've sketched out as the secondary role there require a top decile programmer.

The median level of skill and conscientiousness (particularly) is just so low.

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.