Quick (and cheap?) hires are not necessarily good hires. In my experience (and my theory) developer productivity can range from 0.5x to 5x and more, and those developers in the upper range tend to look for certain programming language which they enjoy, like Rust, Go, Elixir, Scala and Clojure. They are hard to get if you are on a "boring" stack like Java, NodeJS, PHP. So if you might need to invest some time and money to find the right people, but at the end you make a better deal: Even if the salary is twice as much, the productiviy is even more. Additionally less people means less communication overhead, which is another advante.

I find the opposite to be true, that best and most productive developers tend to be more language agnostic than average, although I'm not saying they don't have their preferences.

Specifically, I find language evangelists particularly likely to be closer to .5x than 5x. And that's before you even account for their tendency to push for rewriting stuff that already works, because "<insert language du jour here> is the future, it's going to be great and bug free," often instead of solving the highest impact problems.

Oddly, I think both are true, at the same time.

I've worked with language zealots and it's awful. Especially the ones with the hardcore purely functional obsession. But that can apply to almost anything: folks that refuse to use anything but $TECH (K8S, FreeBSD, etc). Zealots like this general care less about delivering and more about what they get to play with.

Then you have the folks that care about delivering. They're not language agnostic, they have strong opinions. But also: they communicate and collaborate, they actually CARE: they have real empathy for their users and their co-workers, they're pragmatic. Some of these folks have a lot of experience in pushing hard to make things work, and they've learned some valuable lessons in what (not) to do again. Sometimes that can manifest as preferences for languages / frameworks / etc.

It's a messy industry, and it can be extremely hard to separate the wheat from the chaff. But a small team with a few of those can do truly game changing work. And there's many local optima to be had. Get a highly motivated and gelled team using any of: Elixr / Typescript / Zig / Rust / Ada / Ocaml / Scala / Python / etc, and you'll see magic. Yes, you don't need fancy tech to achieve that. There's more than a few of those writing C for example, but you're unlikely to see these folks writing COBOL.

I agree with you but also agree with the above, if youre stuck permanently in some tangled codebase with a boring language/style, the really good programmers tend to find something more fun to work on - unless they can bring their new skills/experience to bear. personally I'll only go back to doing boring stuff if i can't find a job doing the fun stuff

Yeah, this has been my experience too. The mentality seems similar to "productivity hackers" who spend more time figuring out the quickest, most optimal way to do a thing than people who just do the thing.

One of the things I've noticed is that people who just do the thing, take note of what's annoying, and fix the most annoying things about a process later on tend to make the most impressive dents in a system or process, especially since they spend time mulling over the idea in their head and so by the time they implement, they aren't "zero-shotting" a solution to what's generally a complex issue.

Just doing the the thing, oddly lets you sleep on it, and the brain often has the a more optimal way waiting in the morning.

hear! hear!

I'm not in the business of cheap. I do care about resource availability though.

100% agree. You have hit the nail on the head. I went from Common Lisp to Go to now Rust and find that Rust devs are the best so far on average.

There are fewer of them, they ask for more money, but they really are exceptional. Especially Rust devs right now because there are not a lot of jobs you only find the most passionate and the most brilliant in that space. A short window though which will close as Rust gets more popular to startups, take advantage of it now.

In my case, it was definitely worth becoming uncomfortable for a bit to learn Clojure because I was very uncomfortable with the experience of many of the other languages. It’s also great to have endless backwards compatibility and little reliance on changing external libraries baked in.

Never opposed to sacrificing some comfort for learning.

And for superpowers. :-)

This. And End users rarely care what the solution is coded in if it's a tool they use and don't modify or script at the code level.