Posted by spf13 11/3/2025
From the way so many commentators are refusing to engage with the point expressed in the title I think there is collective denial of the core point, so instead, people are discussing the symptoms rather than the disease that is the subject here.
As long as engineering salaries depend on tribal identity markers (i.e. language and tooling preferences) rather than ability to save money, people will entirely rationally choose tools that look good on their resume rather than save their companies money.
I was hired at a shop who had a large, complex Visual FoxPro application they'd developed in house. They brought me in to write a web interface for it, which I did in Python because there was, thankfully, no Visual FoxPro for Web Apps.
I contented that they needed to start a rewrite in something else ASAP. VFP wasn't going to get more supported as time went on. On the other hand, it was a large, working app, and the pushback was "yeah, someday, but for now we're using it to drive the company".
The discussions were always calm, measured, and conducted by adults. We didn't shout or scream at each other, or anything like that. Both sides had reasonable and compelling arguments to support their viewpoint. But from my POV, staying with the VFP app, with the looming deprecation warnings on the calendar, was insanity. Their point was that rewriting the entire, working app from scratch was also insanity.
It's not like a team wanted to rewrite it in PHP, which we can all at least agree would be madness.
That seems like the same argument that TFA is making, but in reverse. I think it's just as invalid. PHP is a perfectly fine language for many things. There is plenty of greenfield development being done in PHP these days + a substantial amount of PHP in production all over the place. Unilaterally writing it off as "madness" seems pretty disingenuous to me.
That was an unusual scenario, however; the previous iteration of the product had major issues, buggy and costly to maintain, and the language change was in part for the purpose of repointing the hiring pipeline toward a different kind of profile. Such special circumstances aside, I'm with you on recommending against rewrites. Much as I'm often tempted.
For some tech choices there was just one clear path from where we are to where we need to go. But for others, the overriding decision was more often than not that some team member had familiarity with the technology. Certainly not the only criteria but enough to tip the scales if it came to that.
If that produces many options, then choose based on the team's familiarity with the language, frameworks, and ecosystems.
A good software engineer should be pretty language agnostic when it comes to work, even if they have a personal aesthetic or technical preference.
> "the framework that best supports the business case and problem you are working on"
by asking the people who will be using it, then the answer will almost certainly be wrong.
The whole point here is working out which is the best tool is almost impossible because of natural human cognitive biases.
TL;DR summary:
No. No, that isn't the answer. It's not even an answer. It's the answer to a different question.
There's another almost-got-it in the article. He is suggesting people tie their identity to their programming language of choice. This seems odd to me, because we tend to think of identity as think like religion or ethnic group, not sub-professional groupings like neurosurgeon or devops, and certainly not specific to tooling ("I'm a DeWalt carpenter!")
The missing connection is back to economics. If I've spent a bunch of time coding .NET, it's going to cost me something to code Java or python. This is the actual economic conversation being had. People will have to learn a new toolset, while having deadlines over their heads.
The solution is actually this: You hire people who are language-agnostic.
I used to spend a LOT of time in VBA, and then .NET. I was daunted by making the jump to C, then c++ and python. Only over time did I overcome the nerves and move on with Java, Kotlin, Elixir, js, and Rust. It was an eye-opening experience that you could do this. Just make the leap, and you find it wasn't that far.
If you don't have people who have done this a few times, you will get resistance, and the real resistance is they don't think it's worth it to put in the hours to learn the new tools. They come up with all sorts of justifications for why things are fine with the old tools.
You'll also become a language lumper if you do this. I don't really think there's a lot of language features. The main ones are GC vs manual memory, strong vs weak type, imperative vs declarative. Once I had a few points on these axes, a lot of things eased when it came to new languages.
I'm not sure that's a correct analysis of their situation. Yes, if you hand a perfectly spherical DeWalt screwgun to a Nikita carpenter, they'll know how to use it, but in practice, everyone I know in the trades has picked a team and just committed to it (to the tune of many thousands of dollars in tools). Fortunately for them, the tools are basically the same, just a stupid bit of plastic (and there are 3d printable or buyable adapters) so it's easy enough to switch teams if they had to, it's just a pile of money, unlike sw tools and materials where I mean, yeah, eventually I got the hang of Ruby, as I did C++ and C and Python and Perl and now typescript and JavaScript oh god and also Swift. (Managed to avoid Obj-C tho!)
It sounds as if you did skip C++ and moved to Java instead. If so you serendipedously avoided the one language that's likely to cause problems. C++ doesn't work like the rest of the languages on your list, and it really is as full of land mines as people say - even though, with a good process, evidently it can be managed.
I think you have it totally backwards for >90% of people, and I counter your argument with a very famous quote:
"Dammit, Jim, I'm a doctor, not a bricklayer!"