Fighting that front and center will make you that hoarding programmer that doesn't cooperate or share, writes horribly obfuscated code and tries to ensure job s

Fighting that front and center will make you that hoarding programmer that doesn't cooperate or share, writes horribly obfuscated code and tries to ensure job security by not just doing things the "right" way. You'll be perceived that way whether or not you're the Mother Teresa of code, so don't do that. An arguably better approach to this problem is to find places where the MS stack is lacking (source control, automated builds, deployment are some things that come to mind from my circa-2003 knowledge of the MS stack) and write scripts that improve your company's development processes. If you do this successfully you might see things change from "we only use $tech products" to "our customer facing, support-requiring products are all written in $tech". From here you have a valid footing upon which to demonstrate the quality, productivity and supportability (be sure you can support these commensurate with the company's need!) of other solutions. Now that you have a footing upon which to build, you can architect solutions that push the strategic part of the products away from the customer facing veneer and toward an asynchronous, nearline component where potential failures won't be seen by the customers directly. You may not be able to get that far, depending on what your products do, but maybe you can take the first step or two, and at least scripting in nicer languages can certainly make the rest of your job a lot easier and more pleasant.