So if I get your argument correctly:

Developers learn a new language that is faster to develop, safer and faster to run than existing solutions (which work but are of increased technical debt) and successfully & quickly port the existing solution to the new tool.

The company doesn't really benefit from it apparently because they never scale enough or because they lacked a target so they had their developers working on sth small instead on working on the company's products.

This skill is highly valued and the developers leave for an other company while the original one struggles to continue.

Do you think that it may be the case that the problem in all these is not within the developers or tool? Furthermore, shouldn't the CEOs and the CTOs know better and to a better job?

> Developers learn a new language that is faster to develop, safer and faster to run than existing solutions

Would that it was that simple. Most of the time I've seen this it's been more like “writing new code is fun, fixing a bad design in our current code is too much like work” without factoring in the cost of rewriting, testing, optimizing all of the code which wasn't a problem relative to simply replacing the hotspot which was.

Yes, sometimes a codebase is so bad that there's nothing of value to be preserved but that's pretty rare and unless it's some turd from an acquisition or consultants the odds are extremely high that the broken business culture responsible for the first bad codebase will cause just as many problems the next time around.

That does happen but in my experience it's far less common than fanboyism or poor architectural/analytic skills — things like spending months rewriting a Python program in Go for a single-digit percentage gain because someone on HN said the magic pixie dust would make it faster and nobody checked whether it was I/O bound, spending most of its time in OpenSSL, etc. I've seen people propose rewriting code in C rather than optimize a database query because Real Programmers use hard things like C whereas SQL is beneath them. (I wish I was making that up)

To be clear: I'm not saying that Go isn't a perfectly fine choice, only that our field is more prone to fads than we like to admit and most of the things which cause bugs or make people wait are decisions higher in the stack.

I understand the situations you are describing and I still have the impression that the main problem behind this is inadequate leadership (and probably at several layers...).

There are more than enough Real Programmers or lacking soft eng who are not experienced or knowledgeable enough to know when to use C/python/go/sql/etc but again for me the problem is either whover hired them and whoever is managing them.

I also more than agree with the last sentence.

I agree that the main problem is leadership — and arguably mentorship as well. As a field we're too predisposed to view all problems as technical and ignore the social factors which lead to the visible technical symptoms.

"Developers learn a new language that is faster to develop, safer and faster to run than existing solutions"

Most often only in the eye of the developers with no proper evaluation.

"Furthermore, shouldn't the CEOs and the CTOs know better and to a better job?"

Yes.

Well, the "in the eye of ... with no proper evaluation" argument can be had for a lot of other aspects of software development and product management, doesn't it?

Hell, I've seen this as a lead/senior engineer. I'm seeing it right now, in fact, as a person on our team wants to write some stuff in language X, which nobody else on the team has experience with, and which isn't used anywhere else in the company, and to solve a problem that is perfectly well solved (in both development time and performance) with the language and tooling we already use.

As far as I can tell this engineer just wants to stick "built stuff in X" on his resume. He doesn't have a good reason to not use our existing stack. If I were the manager I'd demand more technical justification.

But this also might be a problem of a company not providing any improvement / career prospects for your programmers.

If working as a programmer means sticking to C# or Visual Basic or Python codebase and just working on adding new features or new business logic to your application for years and years, many engineers will not find that fulfilling. The best engineers will always want to learn about new tech and approaches (dev ops, containers, PaaS, automation, new languages and tools, AI / machine learning etc).

You cannot blame them for leaving. What you should instead do is provide interesting challenges for them, if they want to use some new technology, work on finding a justifiable use case that management will approve for it.

I understand that for a company that treats tech as a cost centre this approach makes sense but then they can't wonder when best engineers keep leaving to proper tech companies that do actual R&D and where they can become best engineers they can be.

You need to allow your best programmers to learn new tech and progress in their career or else they'll eventually leave for greener pastures and you'll be left with mediocre people who are content and don't want to learn new things.

It's like that analogy I have heard over and over again.

CFO asking CTO: What happens if we invest in developing / training our people and they leave?

CEO replies: What happens if we don't and they stay?

This has nothing to do with whether engineering is a "cost center" or not. It's about fundamentally what is important about the practice of engineering. Whether to use Python or Go or Java or Rust or whatever is rarely anything other than bike shedding. In those cases where it's not, the key problems are rarely which language is technically better: more often the problems are associated with labor supply and how well the proposed language' ecosystem plays with existing implementations'.

To be fair I've been on the underling side of that where I wanted to build some new server we needed in a new language (coincidentally, Golang), but it was honestly just for curiosity/shits&giggles. It became somewhat of a running gag for ~5 years where every new service we needed I'd suggest Golang.

I'm a senior engineer and I'm also the person that wants to use the shiny new thing.

I'm just learning Go and I'm itching to find a project to use it on. It's super hard to justify it though when C# or Python would work just as well and those are languages that we already use.

The best time to do it is on a new project or component of an existing system, in my opinion. It doesn't make it a good idea, but it can be a nice way to introduce something new and possibly more productive.