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. But if I'm working at a large enterprise and increasing productivity may only lead to laying people off I have exactly zero motivation to share something like this.

In 1995 I had my workstation audited by the IT department. A couple of days later I'm called into a managers office and told that I'd broken policy by installing unlicensed software and that I'm in serious trouble (I was a subcontractor from the department major vendor, this manager couldn't actually discipline me in any meaningful way)

I hand wrote them licenses in perpetuity to the half-dozen utilities that I'd written. One was simply two API calls, it popped a message box, and if you hit ok, would restart windows without rebooting (win16)

You're way too nice.

but window dressing because unenforceable unless the subcontractors contract assigned all work product to the payor - this rather neatly turns the responsibility for unlicensed software in production over to the manager, who should have at least passed that to legal for dd, failing which I am tempted to presume that the manager was not acting in good faith.

> failing which I am tempted to presume that the manager was not acting in good faith.

That was my impression. It looked like he saw an opportunity to rip off a bunch of neat software (without knowing exactly what it was he was acquiring) for no money at all.

The question I have is how did incentives get so misaligned that this person feels that doubling the productivity of all their peers is unlikely to be worth the effort of presenting a tool.

It's simple: What's the company's response to the tool?

Is it a percentage of the money saved? Absolutely not.

Is it a raise? Unlikely.

Is it a pat on the back? Maybe.

Is it more work, and a lot of pain supporting the tool in ways it was never meant to be used? Absolutely.

And it'll also mean a larger workload and more stress now that the company knows how much easier the job is now.

With that outlook, why would they share it? It makes their life better and easier as it is, and releasing the tool is all or mostly negative.

And maybe once they find out how long you've had such tools you now get a lot of grief and blowback for not sharing sooner even given that list you just wrote. Could easily be a fraught situation.

and maybe let colleagues get fired because they do not need anymore worker...

I could see not wanting to support a tool. I've written tools that automate processes in useful ways but the interfaces aren't perfect and you need some base knowledge to understand how they work. I don't want to spend my time improving and supporting those tools. I wrote them to reduce the amount of work I have to do, not add yet another responsibility.

I've also made the mistake of sharing my tools only to find criticism but no offer to help make improvements. Fuck em, wasting my time.

> I've also made the mistake of sharing my tools only to find criticism but no offer to help make improvements. Fuck em, wasting my time.

Have experienced a ton of this too. One of the biggest internal tool mistakes of my career was to ship a tool like op's: Got yelled at for using company time to work on non-sanctioned work only to have the person yelling at me end up using my tool for 6 years. Colleagues would get pissy with me when drift happened never updating the tool themselves. Was in a weird position where I had no actual "sanctioned time" to work on the tool but was still required to support it.

But... the biggest rub: my manager (yeller from above) took all of the credit when upper execs eventually caught wind as client-facing changes were happening literally days faster. Something about "building a dynamic team where people are allowed to innovate" - my name wasn't even brought up according to the exec that I was close with.

If I could go back and redo everything I'd hide my work as it caused me nothing but pain, suffering, and bitterness. The reward for good work in so many places is a crack of the whip and more work.

To prevent someone taking credit you add a splash screen when the tool starts with your name on it. Same with the help -> about section.

sounds like you should have enforced your moral copyright for credit. Being denied recognition as the creator of a work is a offence and the circumstances look like a judge would direct a jury to apply statutory punitive damages, making it a relatively straightforward no win no fee case to take. IANArealL just had the role as a general partner with unlimited liability for 23 years in a computational advertising company.

If the incentives are right, that effort is worth it. By incentives I'm not talking about a $15 TGIFridays gift card and a mention at the company meeting, I mean a meaningful portion of the value generated, rewarded quickly not "maybe next annual review".

Many organizations punish the members who work hard with more uncompensated work like you have described.

Oh for sure. If they offered stock or options I'd take them up on it. Cash? I already make a good salary. Kudos? lol.

I don't think it's lol worthy despite having been the other side of the situation for most of my career.

A patent you'd want credit for. A journal paper co-authorship likewise.

I'm very much in favour - especially for non contract LOB works - journalling moral copyrights formally.

Of course we've Github and the similar now, which is amazing, if you use it for such. I am currently working on a possibility to open source a range of advertising trading middleware (dates me, huh?) with the establishment of a Community Company* copyright holding structure that rewards individual contribution regardless of origin, weighted by calling / execution paths / additional necessary weighting as necessary, enforced by statutory articles of association bound in incorporation.

* Industrial and Provident Society : https://en.m.wikipedia.org/wiki/Industrial_and_provident_soc...

articles of association bind the company members to the terms of their articles which are imbued with the same statutory powers of Companies Act, which has 400+ statutory summary criminal offenses adjudicable in the Companies Court. Companies Court, like Ecclesiastical, isn't very well known to even exist, even among the legal profession. However, very much unlike claims heard in the Chancery Division (which must be for greater than fifty thousand British pounds or go hence to the County Courts which exist for extension of the High Court originally for handling the volume property claims, and before which I won't give the most robust tort better than a bitten nickel worth chance.)

edit was unfinished, mea : unlike in Chancery, claims in Companies Court go quickly, because the weight is summary and summary findings of breaches of Companies Act are Criminal offenses, and therefore will shape the further claims evaluation considerably. It's almost a British Delaware system, and in keeping with the theme of this discussion, I was reluctant to write this, lest case load spoil the advantages!

  > I could see not wanting to support a tool.

I had one time written a small tool to reformat a CSV file for one of the office workers. One day she comes to me to make some change to the tool, but I was extraordinarily busy with my real work - and I only came in that day because there was a fire burning that I was best suited to putting out.

So my refusal to drop the emergency that I was fixing (on my day off) in order to modify this tool that had already saved her probably tens of hours of tedium, let to resentment and ultimately to me being fired from the place.

I'm in a much better place now ))

>> So my refusal to drop the emergency that I was fixing (on my day off) in order to modify this tool that had already saved her probably tens of hours of tedium, let to resentment and ultimately to me being fired from the place.

Man, we live in a society… glad you are in a better place now!

Yeah, the people who could appreciate me, the developers and developer management, were ultimately less influential than an administrative staff member. And this was a software business, writing software for clients. Not a software division of some larger entity. One grudge is far more powerful than a chord of appreciation.

Nobody cares about 'the company' - "In US the average share holding lasts just 22 seconds"

Management can break the law, leave with their bonuses, and years down the line 'the company' gets fined.

Employees are the ones that might be there for decades, but the anglosphere shareholder model allocated 0% stake to employees.

TThere are alternatives:

Codetermination in Germany is a concept that involves the right of workers to participate in management of the companies they work for.

The average is probably horribly misrepresented. There are a ton of super long holders, which hold for decades, and a crazy high number of HFTs running that hold for microseconds. I bet nobody is actually close to the average, 22 seconds is extremely slow for software trading and extremely fast for a human. If you're using the holding duration as a proxy for people caring about companies, I think you are probably including a massive amount of HFT timing which it's clear isn't representing company loyalty. Also, what if an HFT buys and sells the same stock 1M times. The average time would likely be very short, but the "loyalty" could be 100%. Bad metric.

Very, very few people hold stocks for multiple years, so they have no reason to care about the company's long term future:

"There are different ways of slicing it, but Reuters calculations based on New York stock exchange data show the average holding period for U.S. shares was 5-1/2 months in June, versus 8-1/2 months at end-2019."

> Codetermination in Germany

For some reason, at first, I read this as "Code termination" (not co-determination) and thought it was a mistranslation of some German compound noun, and I was confused.

TTS on Mac also reads it as "code termination"

Because making it work the way YOU want can be far easier than making it work the way 50, 100, 200 people want. And once they see you as a supplier of thing they'll expect you to give them what they want, because that is how people are.

Exactly, a classic 95:95 scenario. You can build 95% of the functionality for yourself pretty quickly but getting it to work for 20+ people will end up constituting 95% of the total labor if you choose to do it. There has to be a serious reason to take that on. If nobody's asking for it it doesn't feel like a smart use of company time or personal energy. Thats been my approach at my current company and it's kept me in a pretty positive / non-toxic place with the rest of our staff so far.

That said the original comment doesn't seem to be coming at this purely from an angle of practicality.

That is a fair counterpoint. For me it was pointing out there are reasons not to do it that isn't simply being selfish. If a company wants to invest in tooling (a smart thing to do, one of the appeals of Google beyond their comp is they invest in state of the art in house tooling) they should pay staff who's primary job is in the creation and maintenance of tools to increase developer productivity/satisfaction/etc.

Have you ever tried to get something you built deployed into a company where you work?? I didn’t learn the lesson the first time so I’ve tried it twice.

If it goes badly, get ready for a fight. Some cats gain psychological comfort out of knowing everyone is doing exactly as they’ve been told. If you have one of those in your leadership chain, they’ll start questioning every single thing you have ever done. If it goes down this path, you’re fucked. You either shouldn’t have used it at all or you should have told them six months ago.

It doesn’t matter if you only built it three months ago.

If it goes well, you get to go through “code reviews” so it can be rolled out to everyone. But these aren’t the kinds of code reviews that help, they’re the kinds that demonstrate precisely why the company wasn’t capable of building it themselves. If you pass that stage, you’re the maintainer but since you built it on your own time, you can support it on your own time too.

If you make it through that stage, that’s when the feature requests start rolling in. No matter what you built, it will become a time/productivity tracker. That’s around when you start losing relationships with coworkers. You’re management’s bitch but they don’t see that. Instead, you’re the dude whose ‘simple’ tool got shoved down their throats because you want to be VP Eng when you grow up.

Humans are fucking weird. If you ever want confirmation, try to help…:)

It's remarkable how dysfunctional some organisations can be, especially larger enterprises.

Then you have the problem that the reward for good work is almost always more work.

Exactly. So give them great work maybe a little bit faster than everyone else and they will just think you're working really hard!

I don't know the particulars of the situation of course - I imagine there's a big bump in work involved between making a tool useful for its creator and making it idiot-proof for one - but I have observed that as organisations get larger predictable performance becomes much more valuable relative to outstanding performance.

I think it's a side effect of Milton Friedman's Shareholder Primacy Theory, which people interpret in different ways, sometimes, resulting in very skewed incentives.

Another small issue is that the company I'm at is kind of risk averse and try not to use custom tools built by individual devs. They've done it once and now they are stuck with that one tool(also a kind of custom compiler like mine)but the dev is long gone. So unless it becomes an official feature of our systems and some team (not an individual) can support it and there is a clear tech/business benefit, they would most likely deny the dependency. And to be honest, it has kept things sane/boring. It's good stewardship in my mind so I'm at peace with their apprehensions.

Telling them that I use C# will just paint a target on my back since everyone is anti Microsoft and they cringe if you mention anything Microsoft related.

Other than that, there is a ton of admin/red tape to get past if I want to introduce it as official tools and some team needs to be able to support it.

My intentions are actually not malicious at all, I'm just reducing my own frustrations and avoiding adding more stuff onto my plate.

Nicola tesla advanced civilisation yet died poor and alone. Meanwhile someone else made a fortune

And then what? What makes you think the leaders/rulers of our society will then somehow “pay us back”?

You’ll just end up broke and without a job.

2/3 of all jobs are widely accepted to add no value to society[1]

2/3 of all consumption is accepted to add no incremental happiness[2]

2/3 of all CO2 emissions can be eliminated through careful lifestyle management and community design.[3]

These quantities do not seem coincidental and they point to a better way of doing things.

You're not wrong, there's no incentive currently to 'pay us back'. But collectively we are working three times as much as necessary so we can afford things that don't make us happy, and there is no way to sustain that state of affairs beyond the next hundred years or so. Scamming or strong-arming the ruling class into paying most of us for work that doesn't add value may be in our best interest in the short term, but for the long term we need to start acknowledging that it's not in anyone's interest that this state of affairs continue.

[1]Bullshit Jobs, the book [2]the Financial-independence-retire-early (FIRE) community [3]studies I came across in my degree on sustainable energy engineering

Leave it to HN to argue that getting rid of jobs will reduce the carbon footprint of corporations.

I mean you’re not wrong, once we purge a large chunk of the population, since ya know, they’ll have no way to provide for themselves, we will have a much greener planet.

That is a pretty bad faith interpretation of the original argument. You are assuming (incorrectly IMO) that the only purpose of people is to do work. While work is important, I think humans are inherently valuable, even if they don't produce anything else of value besides themselves. Instead of creating fake work for these people to do, I'd rather they just be provided for without doing fake work that accelerates us towards apocalypse.

Are you for paying people to do work that doesn't add value and consuming crap that doesn't make us happy? Because I said nothing about 'purging' or any solutions at all for that matter. I just pointed out that these three problems are in an important way just one problem.

I'd actually seriously like to know, do you want people to have to do work that doesn't add value?

I think what he's saying is that we will probably never build safety nets strong enough to provide for those who had their jobs automated away. They will be condemned to a miserable life of poverty, provided with just enough to keep them from rioting on the streets.

Source: I used to be on SSI disability. This is income for those that are so disabled they are never expected to be capable of working. The average SSI payment is something like $585 / mo. Well below the poverty line and any dignified existence. If this is how we treat our most vulnerable, how will we treat those who have simply been automated out of a job?

That may or may not be true, depending on any number of factors. But that the current state of affairs is neither desirable nor possible as a long-term steady state seems to me self-evident. And yet to my great surprise, this has turned out to be one of the most controversial things I've ever said on HN.

I don't want to do bullshit work just to be entertained.

I want a society were no one needs to work and we only reach it when the amount of people we need is getting so much less that our society needs to rethink this "work".

Without a job? My work ethic is to work in a way that I'm not needed.

And still I'm needed but instead of doing the same old shit everyday I can innovate because I don't need to fix old shitty written stuff.

You're actually right. The goal is to automate all work to the point there is no need for an economy. In a post-scarcity society there is no need to economize.

However, it's a mistake to believe the rich and powerful will allow such a society to exist since they'd be powerless in it. They will impose artificial scarcity on it in order to maintain the existence of capitalism and their fortunes. Just look at how copyright is ruining free computing and the free internet.

>it's a mistake to believe the rich and powerful will allow such a society to exist since they'd be powerless in it.

I'm having trouble imagining how such a transition would even look. I mean, do we still have some sort of recognition of property rights for existing property? If not, then how are the currently owned resources "freed"?

If so, then the wealthy would still be wealthy and there'd still be "classes". So, I'm not sure they'd mind so much, but for consideration of their offspring (which I don't discount).

In either case, how do we go about allocating future resources?

Apparently the working class is doing there part as well to keep the status quo when I see the reaction of others to my statement.

I don't think this is accidental. There seems to be a deliberate effort to de-politicize the economy and to de-economize politics. The left used to be all about labor rights. Now it's about gender politics.

Lol, it's the fault of the working class that they're oppressed? Strange world view.

Fault is a rather morally strongly conoted term, but from a cybernetic analysis, the working class is contributing to the positive feedback loop of is own oppression.

That's not to say individuals that compose the class are all willingly and stupidily acting against their own collective best interest while being convince there's a better practical way they can afford to realize with only marginal chances to end up ostracized or severely punished for the sake of the example.

Lol. BRB lemme make my job and the job of others obsolete and hopefully society will also happen to reevaluate “work” just in time so I don’t starve to death.

Do you understand how dumb your logic is? Or are you going to continue to hand wave literally everything

> Increasing productivity never lays people off, unless the people were originally being unproductive.

Maybe in some imaginary world with spherical cows, infinite demand, and no friction (physical or transactional).

In the real world, increasing productivity so that one person can do the job that ten used to do very often results in layoffs. 70 years ago there were hundreds of thousands of telephone switchboard operators in the US. Productivity increased and they got laid off.

This is so true. Anecdotally, my dad worked in FABs on chips and stuff in the 90s during the dot com boom before they stripped all those jobs away to outsourcing and it basically destroyed him as an older man. Funny how we're desperately trying to get the silicon manufacturing back after we sold out.

"Hey, it improved the financials since it moved from capex to opex. Also, I got my bonus and jumped ship before the excrement hit the cooling unit."

Yeah, several years ago, our corporate overlords sold off a database we created to a competitor and leased it back from them. Now, we're trying to recreate that database to avoid the financial overhead. I'm sure at the time it made sense to some bean counter but it was penny-wise, pound-foolish in the long term.

I think now it's impossible to think long term financially. Thanks, Wall Street.

Reducing head count is literally the core sales pitch for a ton of software and or solutions out there today.

They won't put that in the end user facing presentation, but you can count on it being part of the executive pitch.

once again this is a clueless understanding of increasing productivity.

If I build a tool and make a person irrelevent, then I didn't increase productivity of the laid-off worker. I merely increased my own productivity.

What OP said was his tool specifically increased the productivity of all other users, which means his team can churn out features faster.

Show me a management team that says no to it

That's easy: a management team that only needs ~X new features per month, not 4X. No organization has an infinite demand for features. If they currently have 50 devs working on the platform, maybe after quadrupling the productivity of each dev they'll keep 20. Speed of development increases by 60% and they save 30 developers worth of expenses, which means hefty end-of-year bonuses for every manager up the chain. More likely they keep about 13-15.

It's naive and boneheaded to insist that productivity increases never result in layoffs.

>Increasing productivity never lays people off

Once, I worked for a medical claims company. We had a dozen people who just worked on processing claims. I wrote some software that cut the claim processing time in half. Instead of finding new work for the claims processors, they literally laid off half of them. I have never felt worse, as a software developer than I did that day. Management was so short sighted at that company.

Management commonly has a dumb understanding of economics and management. Particularly when they view engineering as a cost center.

To the untrained eye, it definitely is a huge cost center. Devs and smart people get premium dollar for their work, as they should, but for the bean counters, execs and bad managers, it's extremely difficult to simply quantify the work in such a way to see it as a value add. Especially in an executive excel sheet/powerpoint

>> it's extremely difficult to simply quantify the work in such a way to see it as a value add.

Which is often the case even in product development. They know the existing product is only going to be useful for the next few years. They know they need something new to build on the line. But somehow the development of that new thing is seen as pure cost rather than an investment in the future.

Nevermind how work and production is the bare minimum price of being a business

> Increasing productivity never lays people off, unless the people were originally being unproductive.

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.

This comment is absurd. I cannot for a second fathom how you came to believe so naively that’s productivity increases do not result in lay offs. Seriously how did you come to that conclusion? I’m just curious because it’s so disconnected from reality I can’t figure it out.

Also, your assumption about tooling is 100% incorrect as I myself have written tooling that was saving an org 35k a day, in a single market.

Most people have a poor understanding of 'increasing productivity' especially what OP is talking about.

If I build a tool, that makes someone else irrelevant, that increased my productivity, but not the person who is now irrelevant. Yes, that person gets laid off. So, your tool leading to firing a legal assistant is not what we are talking here.

If I build a tool, that makes every other developer more productive, then the team can build more features or fix more bugs.

Show me one software team that doesn't have a backlog of bugs and features that would not benefit from increased productivity and leading to laying of people in the team.

>Devs should stop being delusional about their self-importance in these things. There are 100 other factors going on in an org and your one little tool ain't gonna make a penny difference in the profitability or productivity of the company (unless you have data to prove it, including impact on profitability)

This is false. My org has seen millions of dollars of savings many times on the backs of tools. Improving developer productivity, and it sounds like ops tool would be huge for productivity, is extremely valuable.

You may be correct but still, this made me literally laugh out loud.

Kind of similar but maybe in a different context—there are a few tools that I’ve written for myself that speed my work up significantly but I haven’t widely disseminated. It’s not because I don’t want my coworkers to succeed, but more that my tools are directly mapped to the way my brain and hands work. Ie, I’m much more of a shell guy who likes to write command line scripts to speed things up while most of my coworkers prefer heavier IDE/tools/plugins to assist (no judgment either way, its just how our brains work). I offered some of my tools a few times but no one took me up so I don’t bother anymore.

Generalizing a solution, becoming a product owner, maintaining it for others, or even worse having some douchy manager take your idea and ruin it, seems like it would be way more work than I can handle and still do my day job.

When I was first started my career I was working at a small software company. I spent my evening and weekends building tools and plugins to optimize my workflow and I quickly became 10x more productive than my coworkers. I shared my tools with the company and in return, I was rewarded with raises year after year. I went from 30k to 80k[0] in 3 years. Now I work for a large software company and the same tactics haven't worked out in my favor so I just keep everything to myself. In my experience not only did I continuously get paid more but everything I wrote was FOSS so it helped improve my portfolio. The catch is you gotta work for great people, and that's hard to find.

[0] Almost double the median household income for my area.

Making it broadly available could also potentially just set a new floor for productivity in an industry that doesn't always reward such gains commensurate with their value, i.e. you'd get an attaboy and "alright well now you can do three times as much work for the same pay!"

This is what happened in my first job out of college. I joined a publicly traded software company and was helping marketing drive leads.

This involved calling engineers at their desks and offering workshops where they got some continental breakfast and to try out some very expensive IC design tool.

The company had a web application written in ColdFusion that had a bunch of forms to fill out each time a phone call or email exchange was performed with a lead. Enterprise sales would use this information to move sales through the pipeline.

I got bored really quickly of tabbing through the page and the repeat data entry based on call or email outcome. So I found a windows macro tool and wrote 5-10 macros that handled 80% of all call outcomes, making it trivial to add details.

Ideally, the web application would just get this kind of automation. However, some of the macros were campaign specific--they just didn't do it.

When my manager saw how I was pulling off the call volume and results, (which were modest--it was still largely cold calling), everyone on the team got a license to the macros and I was asked to share the macros around.

They were all RCGs or recent masters grads, so it wasn't really a problem. But it immediately set a floor for "why are you typing that and using your mouse to finish this call? We have a tool to do that" kind of thing.

Yeah. Why would anyone do things that reduce their own leverage? Assuming rewards proportional to the value of one's work is magical thinking. "If I save a company $100,000, they will give me a significant portion of it." No such deal exists! They're just as likely to give us raises and bonuses as they are to pocket the profits for themselves and assign us even more work.

I have a nice coffee mug that I got for the end of a multi million dollar deal. I dont drink coffee. They would not have got that deal done without me. As I was one of two people on the planet who knew how that code worked and the other dude left years earlier. They then wondered why my productivity jumped off a cliff.

I'm so sorry. You deserved so much better than that.

I have been thinking this for the last decade of reading this perspective on HN, but it's worth saying: if this is true, it's at best a dramatically bimodal situation.

The incredibly-slack labor market this describes wasn't reflective of my experience or that of anybody I knew as of ten years ago. After a decade of tightening in that market, this is even less true.

As I said, it's likely bimodal: certain geographies/verticals/perhaps specialties probably still afford tech workers a 1990s-like level of market power.

But it's worth pointing out that what you're describing is not remotely the norm for at least some dense subnetwork of labor (of which I'm a part). Further, it's potentially the case that entry into this labor market is accessible to those who are currently in the looser market, especially as IMO talent doesn't account for the entirety of the gap.

I don't understand what you mean. Are you saying this isn't your experience?

Isn’t that the whole point of software engineering? You should always be engineering yourself out of your current job. If I’m dealing with the same issues I have today, a year from now, then I’d view that as a personal failure.

The whole point of engineering is to engineer yourself out of your current job? What? I think I must be misunderstanding you. Are people who engineer planes supposed to be engineering spacecraft or consider themselves failures or something? I'm confused.

They are supposed to engineer machines that engineer planes during their free time obviously

Good point. I meant us fake software engineering, not you real engineers with “PE” at the end of your name. My original comment has been clarified.

They engineered themselves out of their current job and still get paid for the job they don't have to do. Sounds like they engineered it pretty well.

I hate this mindset. I’m not trying to make my job and the job of others obsolete. I just want to get paid so I can fuck off and do some other shit I want to do.

There's always going to be people who don't care about/ take pride in/find meaning in their work. That's a totally legitimate way to approach it, but it's sort of an orthogonal discussion to the one we're having.

It's also pretty weird to "hate" that others have managed to find meaning in their work, and discuss the manner in which they do so. I don't get much enjoyment out of cars, but if I noticed that I _hated_ it when others talked about cars and insisted that they treat them only as generic conveyances, I'd probably want to do some self-reflection around my emotional state.

I think the judgmental language is a large part of the reason for the reaction, as the parent seems to be making a blanket judgement of those who aren't engineering themselves out of a job, saying they'd "view that as a personal failure". The blanket nature and talk-down tone of "You should always be engineering yourself out of your current job" is also not likely to win broad support.

To re-use your metaphor, it'd be like a car nut telling you your quality as a person is less for not liking cars as much as they do.

I'm not sure I follow this.

The initial comment was "to do your job well, you should do X". The response was "I hate this type of comment. I don't care about doing my job well".

That seems like a pretty bizarre reaction. If someone said "it's hard work, but you should focus on [XYZ] to ensure your code is well-tested", and someone responded "I hate it when people talk about how to make code more robust. I don't care about doing my job well", would you find that a reasonable response as well? Or in response to parenting advice, "I hate this type of comment. I don't want to have kids". It seems to me that the implicit context for how to do your job well is....people who care about doing their job well?

Most technical jobs aren't like engineering, where the work-product is the process/design and the assumption is that the engineer will be moving on to a new design afterwards. This sounds more like a technician improving their personal set of tools, to me.

Here's some management issues OP might be referring to.

- Who is going to provide support, bug fixes, documentation, manuals, etc?

- What happens if you leave? Can our other devs maintain this?

- Did I mention documentation?

- Did you get this approved by the architecture committee?

- Why didn't you follow our process improvement policy?

- We are a Java shop, so can you rewrite it in Java; you know this, so why didn't you write it Java?

There's also people issues with the other devs who may not like OP's tools or want to change their process.

Having worked in an enterprise this list is 100% accurate. For better or worse (I think it's the latter) enterprises are all about coloring inside of the lines. If you color outside of the lines you may experience functional success in parallel to professional/social failure.

Large orgs/enterprises aren't about solving the problem - it's about the ceremony around solving the problem expecting the problem to solve itself eventually. Going around that ceremony can/will be seen as "going rogue" and will often end in termination of some sort. If the company wants/needs someone outside of that ceremony they will likely go "hire a consultant" vs. trying to find solutions within the ranks.

I'm not supporting this - I'm just saying it's how it is at the majority of larger companies that I've worked for/with. Honestly I think it sucks and stands in the way of real problem solving.

Agree 100%.

Also, there are some very quotable things in your comment.

"experience functional success in parallel to professional/social failure" is my favorite, though.

Thank you!

Source: I work at a huge bank.

Perfectly spot on. It's not about being malicious/apathetic but rather the things you mention above.

My experience is complete opposite to yours.

I've built at least hundred of little tools here and there to improve my productivity to the point where single keypress is what only needed in every other context to run specific scenario.

I've tried to give it to my fellow devs around to make their lives easier.

No-one seems to care enough even to try.

It sounds like you deserve a new job with more challenging peers. Environments like that can suck the life out of a bright flame

Reminds me of a younger self going to interview for the technical team at a bank. I arrived full of youthful zest, thoroughly aced the interview. One of the interviewers, who already looked rather zombie-like, accompanied me to the exit. As I walked off he lit a cigarette and shouted after me, "don't accept the offer, this is not a place for someone like you!"

Made a variety of friends over the years who have shared stories of that bank. It's notorious, the interviewer was absolutely right.

I had a similar in 2000 during the .com bubble, interviewed at an ecomm company doing libraries, Amazon had not yet put them out of business. All c++ cgi. I asked a lot of questions about the stack and dev speed. They had looked at java but didn't have experience so were just going to plug along in c++. Their customers, libraries and book stores, didn't care.

They passed. Reason was I was too much of a cowboy and they were afraid I'd rewrite their whole system within a few months of starting.

I can read that many ways these days but I'm glad they passed ...

I've also encountered this kind of apathy in other devs. I don't have a good answer what to do about it though.

A lot of successful companies are founded this way (Eg HashiCorp, SAP, Basecamp, etc).

Person sees a massive inefficiency at their employer. They know of a way to save time and money by building a tool to solve for it.

That person starts their own business to sell that product to others.

No better way to find product / market fit than to have first hand experience in the problem that needs to be solved.

and more importantly, they get paid in line with what the tool is worth.

This is one of the main advantages to being the token tech person in a non-tech group/organization: They have no idea how I do anything or how much time it might take. All explaining or sharing too much does is cut into my free time and possibly leads to additional competition in my niche.

There are also larger ideas and projects I keep to myself because I think they're viable and useful but refuse to see them ruined by the current scene/think the drawbacks of letting the idea out in our current culture outweigh the advantages.

I don't LIKE either of these things, but it'd be foolish of me to ignore the lessons I've learned over the past quarter of a century.

I get this. If you tell people, and it gets released into the official tool chain, you will also probably then be its "owner". More work for you with no extra money.

I was looking for this among all the responses. Surprised you're the only one who mentioned it.

In my first job, I would make constant productivity improvements like this. This resulted in two problems:

1. The team became dependent on them, but only I would maintain them (management's directive). Although productivity went up, management saw me as the bottleneck because if the tool acted poorly, that team member's work was held up until I fixed it. I ended up with a lot more responsibilities, yet had to keep up with all my teammates who were using the tool to be more productive. That's a recipe for burnout. And except for one bonus one year, I didn't get paid more and it was made clear to me that all this stuff would not contribute to a promotion.

In summary: I needed to maintain all this, do my "regular" job, and had no option not to work on the tools any more.

2. Since management loved all these tools, they decided to own them: Prioritized features, changed behavior for the worse, etc. I now had to not only maintain my babies, but I had no say on the development of said babies.

I was eventually fired for not being productive enough on my "real" work.[1]

I'm not jaded, though. Now in every new job, I test the waters. If management acts this way again, I stop showing people my productivity tools, and slowly look for another job. Often, management really does appreciate and reward me.

[1] Well, and for other reasons. I quit first, and they retroactively fired me :-)

Thanks for sharing. That's sad to hear. May I ask how you find out if management appreciates such productivity tools? In my experience, some people who seem really nice turn out to be extremely toxic and demanding once they find out my potential in doing things quickly and my quality work.

Not only that, but once the company owns it, they'll want to start managing it, making changes, etc. You run the risk of it becoming bloated with features, making it harder to maintain and the whole thing loses the reason it existed in the first place. Maybe that's a stretch, maybe not.

Also, if it does decreases work time by 3/4, guess what happens when the business finds out? Deadlines and estimates get pushed up, and everyone is expected to get that much more done. Sometimes, as a developer, you need a trick up your sleeve to keep your head above water fighting unrealistic expectations. If everyone has the same trick and it becomes part of your SDLC, the goal post just gets moved.

Agreed. Ownership sucks and everybody will duck it even if they depend upon it.

Back in the Bad Old Days(tm) when disks still spun and displays weighed as much as a human, all manner of crap used to go into /usr/local but nobody would ever own it--consequently, you'd have knife fights over versions of Perl, for example. Eventually my VP turned to me as a noted BOFH and asked "This is getting out of hand, should we just delete it?" "Depends--will you fire anybody who gives me static?" "Yes." "Consider it gone."

So, I warned people for 4 weeks that everything not owned by somebody was going away. Then at 3 weeks. And at 2, 1. Then at 3 days, 2 days, the day before twice. Through all this only a single soul signed up (and it was an intern ordered to--we transferred the intern to my group and gave his manager a ding and a tongue-lashing later. But that's a different story for after more alcohol).

And finally on the magic day, I wiped it out (with a backup of course).

All holy hell broke loose. Everybody trooped to my cubicle.

To which my response was: "Great! You're here so we now know that you depend on something in /usr/local. So, which package are you the owner of?" Half of them would start screaming. Probably a third would start begging.

To which my response was: "Look. This isn't difficult. You have a dependency. Sign someone up from your group to manage the dependency. Then I'll put it back."

In spite of that, 90% of them walked away without signing up. Being dead in the water and hoping for some other poor fool to take ownership was considered less problematic than signing up for global ownership of a software tool.

That's how crappy "ownership" is in a company.

Thank you for sharing. I've had one or two similar events over the years. I think often times people don't even know that they are indirectly using something or have indirect ownership of something. Only when switching it off does it get crystalized.

We do currently have an abandoned tool in our chain that was built about 4 years ago but the guy ran away. We have yet to untangle his mess. Our operations/devops units kicks heavily against stuff like this for this very reason.

Unless I can guarantee myself (and them) that my tool will be a very tight integration with the rest of the system and not become a wart, then I rather won't introduce it. It has to fit properly with the rest of the puzzle.

I can relate to this so much. In my first job I was working with analysts who spent a lot of time generating reports. I was a SQL dev who had learnt python recently and automated my report generation. It cut down work from 1 day per report to less than a second. I shared this with my manager who shared it with the team. The team ended up sending me the files for me to run it. And the ones who wanted to run the script on their system ended up having me on-call support half the time fixing issues unrelated to the script.

I cited a system upgrade and informed everyone the scripts were gone. We're back to how we were, except I had a lot of time in my hands now. Since it was my first job I felt bad for not helping out people. After my experience I feel it's not worth it.

You can say the same arguments for having a really well defined customized editor and your coworkers wanting the productivity you have. I showcase using pycharm, but I do my actual work using emacs.

wow, super happy I don't work with people like this.

Why would you care? He's not actively harming his coworkers, he's doing what is asked of him work wise, and his colleagues presumably are too - and are themselves getting apparently slack jobs if there is 6hrs per day of easily automated work. Imagine if your coworker told management about an efficiency hack that made you responsible for 4x the output per day. Would you rather work with that person?

Personally, I wouldn't want to work at a company that apparently is not incentivizing creativity. I'd rather work somewhere where I knew if I did something like this I'd get more money or career progression or something, not just more work to do. But I certainly don't blame the employee for this

Assuming its not trivial, its hiding a useful tool from your coworkers. Why share any knowledge at all? Why mentor someone if it just gets them more work?

Seems pretty toxic to me.

This isn't any different than keeping a bunch of text snippets that you use as a starting point for creating things. Text snippets may seem trivial in comparison to some tool that writes code or checks for your common errors, but when there is a bug in your text snippet, you own the bug.

Let's say he gives away his tool and all of a sudden he is the guy who has to work on it when other people have problems. Now his coworkers have more time, he has less, and he is the scapegoat for when things go wrong. Not only that but since it is not a real product of the organization, no one will recognize the time he works on it so he will have to work over time to meet his other goals.

Now if someone wants to ask for a copy of what I use, sure but they own their copy and I own mine.

Sure, there's plenty of reasons to not push every line you've written. However, the stated reason is to keep a "competitive advantage" against their coworkers.

I took the competitive advantage comment as the short story to a much longer reason.

We started to share those kind of snippets in Operation manuals and knowledge sharing session.

This helps other people to grow.

Cause some of the tools are completely outside of the scope of work or company culture or tech stack.

We do share knowledge but not all of it is relevant, so not every little thing needs sharing. If I come to meeting and share everything in my head I might as well crab a box to stand on and preach to the clouds. I'd rather just get on with things than trying to convince people of my way of working.

No toxic intentions involved here.

If he's got that attitude for this what else does it extend to?

This is the core of the issue: we don't get time allocated for innovation/creativity and other internal improvements. At town halls we get told we need to be innovative but then.. no time is allocated for it. I suspect a handful of other devs also has their own tooling as mine to make their lives easier, but keeping it for themselves, as telling/showing other can often invite unintended consequences.

He/she is blocking a head count for a person who would improve the success of our team and our company.

I prefer people who genuinely like to improve our whole environment than not.

Sharing and caring!

Compensate people appropriately for their contribution, and they will contribute.

I prefer managers who pay me, rather than thank me.

No Bucks, No Buck Rodgers.

And? You think you will not be seen as a very good developer companies want to keep?

You can mention your optimization in every salary discussion etc.

A lot of places would see someone not following development guidelines, doing something unsanctioned, or otherwise not fitting in to the expected culture.

That can be far more toxic pushback to any attempted improvement.

I am not interested in your BS pull system. I do not beg for dollars. Very few people do what I do, and my skills are in high demand. Continuously and proactively compensate me, or I leave, and take my productivity and inventiveness to your competition. Fuck your annual salary review.

I do but the company doesn't care about stuff like this at all. In other ways the company is great but in some other ways not so great.

I do have the urge to share it with others but on the other end I force myself not to do it. I care a great deal. I have shown things in the past, during screen sharing meetings, then I hear people taking screenshots of my work... no thanks.

You wouldn’t know if you did.

You can probably make a good guess though. If you have conversations at work like

bob: "hey come and check out this cool thing I made, I think it could save you a load of time"

me: "woah, nice one bob, that's amazing! Let's roll this out to the other devs"

then you're probably not working with someone like gp.

I would because they'd be more productive than me.

They might be more efficient, but by working 1/4 as much they're equally productive!

Exactly. You get paid for your output, not your effort.

Edit: A deleted reply said “You don't even really get paid for output. Output theatre pays better than output.” Great insight I thought worth persisting.

To be honest, I try my best to conceal my gains. I intentionally time my feedback to when it is expected of me.

Maybe your colleagues haven't asked for it because they built their own, but better, and are only working for 1 hour a day. Maybe you work twice as hard as the rest of them...

I suspect a handful of them have their own tools to ease their suffering, same as me, but most don't and are just apathetic and carry on with their day.

Wait, why don't you want to help your colleagues? That seems pretty shitty.

A possible reason is stack ranking in annual reviews.

I definitely see that in many of the people I work with at my clients. The more efficient staff members typically only share pretty trivial life hack-esque tips. Their comprehensive framework of all of their efficiency tricks? Kept in their heads.

If they share it, they lose their edge against the peers they are ranked against. If they don't share it, they consistently are in the top 5-10% of employees with the most story points each sprint, and they get better raises.

This is an easy decision for the employees to make. You get what you incentivize for.

It’s entirely possible that his colleagues have no desire to be helped, which can happen in a shitty organization.

Seems like better time spent on looking at how to get out of shitty org than gaming the system

I'd be curious to see why you're so confident that OP's time is better spent getting out of this organization where they can work 2 hours a day for what I assume is a decent living.

Financial wellness !== mental wellness.

Its funny how gaming the system is 'innovation' for bosses and 'cheating' for employees

In some cases people play politics: some people are looking for places to find fault or point fingers to if they get stuck, so just limiting the amount of drama in my life.

The code I built is like 500 lines of code, not that complex and any developer with half a brain can build it... so if they want, they can build it themselves. Why should I deprive them from learning how to empower themselves? Its a great learning experience to build tools around your current journey.

And the tools are disposable btw. I've done this at every place I've worked. I have a small graveyard of tools of everything I've built in the past. And sometimes I go and copy code from it for a new tool and so forth. Every developer have a folder somewhere with some cool tools just for in case. If they don't... maybe they just don't care about programming as much as they think.

It's like asking why a mechanic won't share a tool he built by himself for himself, to help him replace a certain part in a car, when he needed 4 arms but only had 2 at the time. He is not obligated to share his tool with the world and keeping it isolated might save lives (lets say there is some risk that someone might die in the case of a malfunction). In the tech world, php comes to mind when I think about releasing things into the wild. I try not to inflict onto others with what is in my head, because how I view the world and how I like to work is not necessarily how other people think.

I work in the Healthcare domain, specifically with medicine and formularies. It is utterly important that we do things correctly. If I share my tools with the others and they misuse it or something goes wrong, and there are real world consequences (a patient gets the wrong medicine/dosage/box or data gets corrupted), then I can guarantee you they will point their finger at me and throw me under 50 different busses. I'm not going to risk that for no good reason.

So it's not as simple and clear cut as just being shitty. I promise you it is not because of selfishness but rather about self preservation (not getting burnt) in conjunction easing my own suffering (cause most healthcare software is an utter shit show, thus my own tooling is just a band aid).

As long as it is only known to colleagues, it is all good, but if word gets out (and the more people know about it and/or use it, the likelier it is), then they may get more work to do and such. Maybe the coworkers do not give a damn either way.

As a contractor, I once made a tool that made things easier for me. The "breakeven" time (time saved exceeded time spent writing it) was a day or two. I made the mistake of sharing this tool and was berated by the client. Every single time after that they made sure to remind me not to work on things "outside the scope" of the contract as apparently writing tools to increase the output they get per billed hour is out-of-scope.

Real time error messages are useful, but I don't see how they could make you win 4x time

You perhaps have never worked in a system where compile times are measured in minutes. There is a point where the feedback loop is so long it’s very hard to keep in your head what exactly you were trying to accomplish with the last change. Getting that OODA loop small enough means flow can happen. Flow allows you to do in a very short time what would otherwise have taken you hours.

Do not underestimate the time and cognitive savings of realtime feedback.

Exactly this.

Many feature request in our system takes 2 hours to implement where it would be 5 to 10 minutes in C#/Visual Studio (with a tight debug/compile loop).

Without real time errors you can't get in a "flow"?

That's hard to believe.

I didn't mean to imply that you can't get into flow with even day long feedback loops. But the flow is definitely more likely to break while you're waiting for the feedback loop. I'm not sure you can really be in flow state between iterations if you're using punch cards circa 1970. But you might be able to reach flow state while writing said code between iterations, you'll just make sure to test more than one thing per iteration if possible. There's also a different state of mind that may look like flow for people who have to wait weeks to see if their code works. I know someone who grew up in a boarding school, and only had access to computers on the weekend, so he'd work on the code all week, only to get a chance to test it at the end of the week. He claims that's one of the reason he's such a good coder today, and I've heard similar anecdotes elsewhere.

But all kinds of things can knock you out of flow and so you might need to develop other strategies to compensate for something like a long compile time. I personally will write code, and every so often fire off a ./compile && flash_embedded_device && connect_to_device command then go back to write more code while I wait the minute plus it takes for me to get to run a test. This helps, but flow would be much easier to maintain if I didn't have to wait more than 5 seconds for the same test.

Not GP, but when you're waiting for three-plus minutes on "did my change have the desired effect," it's incredibly easy to get distracted by "just checking on this one thing" for a minute and completely losing flow. When writing code, sure, but writing code isn't 100% of my job; I also have to build it.

In our system it is incredible hard to get into flow. All of our work is basically intermittent due to the nature of the system.

You are fortunate that you haven't had to deal with it yet, but it's very real, you don't have to believe us.

Our development life cycle is quite slow/cumbersome with crappy in-house compilers that are on life support... yeah it makes a big difference not having to deploy between each iteration and get local feedback while I'm coding.

I cannot elaborate more than that but it is a bit more hairy than I described. My own tools alleviate some of the problems (sadly not all of them). Doing the best I can with what's available to me (basically building workarounds for shortcomings of our systems where I can see holes).

One of the big reasons not to share tools that would otherwise increase productivity in a corporate settings, is that people are petty a*holes. They will fall into at least three big negative buckets.

1. Those who will see it as a personal insult if you write something useful and you will then have a target on your back as they work to block you and hurt your career so you never show them up again.

2. Those who could care less about improving productivity and in fact would rather that everything is tedious, error-prone, and time-consuming so that at least it's mindless for them to go about their day.

3. Those who see everything they don't understand through a lens of fear and hatred. They will not understand your tool OR why it is helpful, and will instead see it as an alien invasion or viral infestation in their workspace, and will work concertedly to resist it.

Number 3 is most common in my experience, esp in dev shops that uses Java. Very averse to things outside of their Java empires.

Another cool one that I've made:

In dotnet there is a package called ssh dot net (spelt out). With this package you can programmatically ssh into your vm's (basically open a normal ssh tunnel from c#). Its great. I use this in conjunction with the postgres dotnet driver to connect to our production databases. I use this when I don't feel good about doing data maintenance directly in sql and need more type safety. So I use my little C# tunneler quite a lot to get my work done quickly and safely, all while the other devs are fighting over vim/emacs vs using postgres in the terminal. So me using my own little tool for all of the risky stuff has been a godsend. That and Datagrip (I have a paid version of this, worth every single penny). The little tunneler reads the database schema when it starts up then generates a class/model for each table so it closely matches with it, that way I can fiddle away and write some clean sql against the db without stress. I know it sound silly but it works great!

So yeah. The company I work for is a strictly-java shop with an apple fetish (so everyone has macbooks). Little do they know I haven't touch the macbook in almost two years. I use my desktop Ryzen pc with a bunch of C# tooling. Ha!

And how do you get around the concept of any code you write on company time, on company resources is owned by company?

That’s a legal construct. The company owns it (in licensure), but he’s the sole user/operator if it.

Right, so if company finds out that you have code written on company time meant to be used to do company work, company can then say that all employs must be able to use that code. OR they could say that you can no longer use that code. No longer abiding by either mandate could be cause for dismissal.

Legal construct or not, it is a work product that would be owned by the company. Using that code at a new company would be wrong as well.

It’s unenforceable if they don’t know about it.

Sure, if you questionable morals.

This only help msvc devs, who are in vendor lockin disadvantage anyway, and are always 10 hrs behind.

Normal people used flymake on emacs for the last decades, recently switched to LSP feedback or VScode.

Why would they have to pay you a cool sum of money for it? It sounds pretty clearly like you did it for work, so unless you have a very unique employment contract, they already own it.

You are making a pretty good case for why they should continue to not share it with anyone.

Why? It sounds like it's built on an internal platform, so there's no other use for it. Sharing it with other people at the company would at least improve his reputation with those people, which could be helpful down the line.

For work sure, but it also sounds to me that it was built during personal time.

If I use my own time to make something, work isn’t getting it without paying for it. I don’t care what the contract says about personal projects (although I‘ve also never signed one of those “we own everything you do outside of work” clauses because I find them exploitative and abusive)

> (although I‘ve also never signed one of those “we own everything you do outside of work” clauses because I find them explosive and abusive)

Me too. I always ask that it be removed from the contract, and so far, it always has been.

When I was working as a web developer for a company, I published a game I spent many years dreaming of, and in real terms thousands of hours learning and creating. I wrote the music, drew the sprites, coded the game loops, purchased all the tools, built it using my own hardware etc. The CFO at some party or other after a few beers told me if the game actually became successful, there was nothing I could do to stop them claiming ownership of all of the IP because of a clause I'd signed at some point.

Since I left that place and I believe most of my time-limited terms have expired, IP is one of the very few things I'll get caught up on with a contract. I'm flexible around hours, reporting, attire, presence, etc, but IP outside of specifically client-related work activities is where I draw the line.

I am a digital creator on my own time, I always have been since I was a child, I draw inspiration from many sources, whether it's work or books or videos or art, or even just a random thought. The notion that one day one of these things randomly becomes successful and a bevy of previous clients lays claim to the fruits of my labour sickens me to the core and goes against every sense of living in a fair and just society.

I've knocked back clients who refuse to budge on this issue. I'm no Bill Gates or whatever, but there's absolutely no way I'm signing over rights to things I invent or innovate on my own time. If the people I work for want access to that additional service beyond whatever monkey-shit I'm doing for them then they can pay for it and not just swipe it through some boilerplate IP clauses.

I agree with you on the personal projects stuff and have also had that language struck from contracts (I've published a couple of short books on Amazon and had one contract that pretty clearly said my employer would be entitled to profits from those books... pass).

But in terms of building it on personal time, I'm iffy on that. Obviously in tech the time tends to blend together... I've worked on weekends but also spent half a day doing personal stuff when I'm WFH and I have very little on my plate. It seems to me like the more relevant fact is that he clearly built this for his job - to me, that makes it feel like this is a situation where the employer claiming ownership isn't abusive at all. If he never would've built this if not for being employed at that job, and he used it primarily in that job, isn't it fair to say he made it as part of the job?

My contracts either stipulated set work hours or was contract work for which I billed for the hours. If the project is completed outside of the stipulated work hours or not billed for and not using company resources such as computers, then they have no claim to it.

If I’m meeting my contactual obligations, anything more is mine. If I go above and beyond, then that is, essentially, a gift from me to the company, because I’m only compensated for what the contract says I’m compensated for.

If I spend my leisure time to build something that makes my job easier, I see that akin to using the time to go to the gym or get more sleep because that also makes my job easier. If it’s my leisure time, what I do is my business even if it helps my work.

Of course we don’t know when this person built the tool and maybe it was done in a less clear way. I always try to keep things I do for myself clearly separate. Eg if I’m WFH and the last hour is quiet maybe I’ll also put some food on while I finish work, but I would never use that time to work on a personal project but rather wait until I’m clearly clocked out.

Uh, because you could get 4X the "amount of shit" done in the same amount of time? So ideally they should pay you 4X.