That has not been my experience. In a C# shop, if you want to do something not-C#, best is to switch employers. I don't say that placing such high value just into what tool you use is smart; but changing tools in a company is often a total no-go.
I have been told many times in the last 20 years that the only thing that gets used comes from Microsoft. Literally the same shops end up with several piles of unmaintained crap which is either "not invented here" stuff, abandoned microsoft frameworks and all the staff have left to go find another job because it's not shiny any more.
Behind the enterprise tooling propaganda, there is the real programming endeavor with whatever tools are appropriate for the tasks (given the constraints of time, team size, developer expertise, maturity of libraries, etc.)
A software development business is not really about programming languages, libraries, or tools, but about the game of power in the organization (even when the end user doesn't care how the product was developed). Anything that threatens that power is easily dismissed.
A NIH attitude is kinda the the opposite of what I meant. Choosing the right job for the tool, would mean that all the wrong jobs should be outsourced.
> Choosing the right job for the tool, would mean that all the wrong jobs should be outsourced.
outsourcing that is just "kicking the can down the road" some poor developer is still left dealing with the same problem. It doesn't change anything other than who has to do the thing you don't want to / don't think is right.
I've done the opposite, striking out C++ code in a mostly C / Python shop.
In practice, it is far more important to allow your team to function when you eventually leave. Otherwise, they'll just throw your code away. Fortunately, a lot of code is thrown-away. So maybe it doesn't matter. In this particular instance, I knew my C++ code was basically a throwaway script (and Python, the other language that my fellow coworkers use, was too slow to get the job done).
But if you ever create something that truly matters and needs long-term maintenance (which I have), it better be written in a way that the team can maintain that code. Writing it in the language your coworkers speak (that the managers are hiring / interviewing for, etc. etc) is very important.
This brings to mind the joke with the drunk looking for his car keys under a street light. A guy tries to help him, and after searching in vain for a while, asks him:
"Are you sure you lost them here?"
"No, I'm pretty sure I've dropped then somewhere in the other side of the parking lot",
"So why are we looking for them here?"
"Because there's more light here which makes it easier to search!"
So, what's easier is not always what best. E.g. it doesn't mean sticking to the job rather than the preferred tool is the optimal path to expertise, career success, or personal development.
I think it is easier, but I don't think that is important or the right question. We live in a world that evolves and problems (Jobs) change all the time. It is to everyone's best interest to teach themselves new tools both to stay relevant and also to find interesting new problems to solve. So yes we need to change from the mindset of religious worship of a certain tool by only searching problems that tool can solve to researching the best tool for the problem we need to solve and learning it if necessary.
you generally have an established codebase of tens of thousands of lines of code that the business is based on... usually with little to no test coverage. Creating a parallel version of the code in the new language would take ages and be filled with errors because the lack of tests proving the behavior in the old one means you rarely know if you new version is "correct" or not ... and then you end up with annoyed customers but... all of that is moot because you can't get management to sign off on using so many resources for so long to do a thing that customers will never see and can't be marketed.
