3 ms·

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

by eurg 7y ago

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.

m0xte 7y ago
Yes totally that. 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. Also a bad outcome.
- mpiedrav 7y ago
  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.
- im3w1l 7y ago
  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.
  - masukomi 7y ago
    > 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.
dragontamer 7y ago
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.

by eurg 7y ago

m0xte 7y ago

Yes totally that. 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. Also a bad outcome.

mpiedrav 7y ago
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.
im3w1l 7y ago
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.
- masukomi 7y ago
  > 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.

dragontamer 7y ago

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.