Earlier quoted context omitted.
A lot of people are assuming the worst intentions here but anyone who has worked in an enterprise knows sometimes it's useful to build tools for your use and not to share. The tool might not even be allowed, C# is probably not in the supported platforms and even if it was, getting it into the official repos can be arduous. If OP really cared about maximizing everyone's productivity of course they would share the tool…
Increasing productivity never lays people off, unless the people were originally being unproductive. That's a dumb understanding of economics and even management. Also, scaling tools to more than one user is incredibly hard. Software development is still custom / art. This tool works because it is suited to OPs workflow and his "way of thinking". In order to make it work for others, it needs lots of improvement and g…
This is either trivial or underdetermined. It depends on how you define "unproductive":
- If you define "unproductive" as "produces at a lesser rate than the new, increased productivity level" then it's just a tautology.
- If your definition of "unproductive" is not relative to the new rate, then you have to stipulate a reasonable definition of "productivity" and show that it was not being met prior to the automation. You haven't done this.
It might turn out that the second bullet is easy enough to do in the domain you're talking about. But it's worth using language precisely if you're going to tell people that they have a "dumb understanding" of whatever you're discussing.