Latest example: at my current workplace we have some crappy custom compilers for our platform.... I've rebuilt them in a way that I like (and using C# instead of Java), that enables me to use it in a small visual studio code plugin that enables me with real time error messages as I code against our platform, so basically constantly compiling in the background as the file changes. It's great. Can it improve the lives of the 50 or so other devs working on the same platform? For sure (it saves a ton of time and frustration). Will I tell them about it or release it onto our private git repo's and make it part of our platform/build chains? Nope.

I can give you 20 good reason why I won't do it but really don't want to get into it. If they want it, they ask for it & while they are at it, they can pay me a cool sum of money for it. Until then, it is my own private competitive advantage that allows me to work 2 hours per day instead of 8. Not embellishing.

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.

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)

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.

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.

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.

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

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.

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 ))

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

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.

"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."

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.

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

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…:)

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

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.

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

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

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.

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

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?

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.

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.

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?

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.

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

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.

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.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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?

- 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.

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.

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.

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.

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.

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 ...

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.

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.

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 :-)

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.

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.

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 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.

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

Seems pretty toxic to me.

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.

This helps other people to grow.

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.

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

Sharing and caring!

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

No Bucks, No Buck Rodgers.

You can mention your optimization in every salary discussion etc.

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

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.

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.

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.

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.

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).

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

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).

That's hard to believe.

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.

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.

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).

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.

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!

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.

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

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)

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

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.

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?

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.

I was young and not exactly entrenched in the culture as I was in the midwest writing code from books without any desire of community, so I wasn't used to opinions.

The negative things expressed caused me a depression since I was proud of my work. Unfortunately, for the business, the right thing to do was to stop developing the language and use shit that the local labor market could handle.

This awareness of what the market could support was depressing as hell, and I eventually couldn't be an effective leader for that company as I was more interested in doing interesting things versus the right thing. I found it boring, and that's when I went into big tech to work on interesting things.

Now, I'm older, and I'm up to my shenanigans again with a new language: http://www.adama-lang.org/

One thing that I have learned is that you can't make everyone happy, but you can make a small group of people ecstatic. Next year, I intend to work on my language full-time (ish) and ship something that people can use with just a command-line.

* https://www.reddit.com/r/programming/comments/6ori0/kira_is_...

* https://news.ycombinator.com/item?id=226480

Some of those reddit comments are less than constructive, sorry to hear you had a bad experience. We're likely worse off as a community for it.

Glad to hear you're back on the horse! Best of luck on your future projects :)

So I made a little code to pull from FM and put into Word. So we could fill these forms, required for payroll, in minutes rather than hours (not a joke). And my team mates loved it. And then our lead claimed it as his own work, presented his accomplishment to the next boss up, bonus, congratulated and promoted. (Fuck you Ed)

Most folk only got they own back.

It had no impact on my career path and I'm still making stuff GPL and BSD and MIT.

Companies are loathe to fire someone without a paper trail. Bring them a paper trail and you can unseat an unpopular manager that their bosses have lacked the evidence to fire.

... sometimes. Sometimes the tree is rotten to the trunk. There's no hard-and-fast universal rule here.

The mobile page asked for the full passcode whereas the regular page asked for specific digits which, while still automatable, wasn't as easy

The code/method might have been useful to others at the time (especially your Mints and that) but I didn't want them changing it. The mobile site was, as far as I could tell, a relic from an older era that I stumbled across by accident

Everything's starting to catch up now so it's no longer needed. My bank now (Monzo) even does webhooks for transactions if you set them up :)

On the topic of YouTube I really don't get the reaction to removing dislikes, seems a bit overblown. I am biased in that I've never noticed them other than that one Futurama neutral video that keeps them synced with the positive votes though (which ofc is now broken)

Incidentally removing the number and replacing it with a big DISLIKE in caps makes it much more noticeable. I am way more likely to click it if the video is bad now, for whatever that matters

Edit for OP edit:

> Now w/o the dislikes count, all devs have a much harder time filtering useless videos

This is the only argument I've seen opposing the removal of dislikes so far. Are there any others? Even silly reasons, anything other than "bad tutorials tho"

Is that argument not enough? It is now harder to distinguish good videos in a video platform filled with sub-par content, any other argument would pale in comparison.

For me, no. I've never used the dislikes for this, it seems like such a crowbarred in reason everyone latched on to for lack of a better argument

I tend to judge the content on the content

It's possible to do it for image and maybe even music, but as with videos, you'd have to spend time watching segments to get a sense of quality. That's arguably time consuming.

The first few comments were negative — not ideal but certainly okay! — but then the author started getting harassed off-site. I was contacted and immediately deleted the post.

Start to finish, the whole process took maybe 30 minutes, but it was sadly instructive and I think about it every time I submit something here. It's probably made me comment less.

Because of a post here on HN? What happened?

It's the kind of thing that you could do by hand, but the website (intentionally?) made it a tedious and time-consuming clicking exercise to compare effectively.

They changed their API eventually, but I made decent use of the script for a couple of years.

To me it looks like the lind of script that, had it gotten traction, Megabus would have changed their interface a LOT sooner (and also I'd be competing with others over the cheap tickets!); so I kept it to myself.

The best part is, eventually you hit things like booking something as soon as it gets online. And it happens so fast you figure out there are multiple engineers out there, each with their own script, fighting it out

I don't see the link with your example. How would people profit of finding the number of dislikes on YouTube?

Also, sharing this would increase the number of users of the exploit, and its general publicity, making it more likely to be fixed. Nothing to do with having each other's back.

And then, considering that you are disclosing a security leak, the "having each other's back" thing to do here is disclosing that to google, not exploiting it yourself

A reason to be afraid to submit may be that the number of respondents that don’t know how to review may exceed the number that do, causing the net result to be more destructive than constructive. Which brings me to another skill — how to ignore input that (even if you receive it) does not really matter, or at least not right away or not as much as other things.

If only as a profession we could resist the urge to quibble about things that probably are fine (or at least not pressing) so that there is more time to dig into the heart of a design or implementation. Yes, that’s an interesting algorithm; no, let’s not segue into the choice of back-end on the web site that happens to host the documentation; yes, that will help with maintainability; no, the number of spaces here does not really matter; yes, that is a good recommendation but not under these time constraints; no, I will not rename 125 variables to suit your arbitrary choice instead of my arbitrary choice.

I would also add that “review” is often misinterpreted as “pure criticism” (again, in code or in HN comments) and it can be nice for unsolicited positive feedback to occur too. Things like “I like how this was done”, or “I’ve never seen anything like that, clever” as opposed to an unending wake of negativity that tries to tear apart any given project.

My opinion is that negativity should be proportional to the stakes.

You try to sell me an expensive product via cold call, then sure be negative.

You try to give me a neat idea for free shared on a website for sharing, then maybe we should all be appreciative of the sharing.

Advice given to me was to post your projects anyway and don't fret too much about the negative comments: you'll always always get a mix of negative and positive comments, everyone does, so don't take them personally.

Some people (like myself) prefer to be treated with more respect than a snarky comment. You can attribute that to being sensitive if you'd like.

I think other commenters think more along the lines of, "It's the internet, I'm (sort of) anonymous, if you don't like what I say, T.S."

Personally, I think that aside from being rude, the comment in question ignores the fact that the original commenter stated they saw other people receive snarky responses, and after receiving those responses themselves decided they'd rather not be criticized. I think they'd know better whether their life or career require exposure on HN.

What do you think would be a productive response to this complaint?

I've seen the argument that in order to engage on the internet you should be thick-skinned and prepared to take a certain amount of sharp criticism if you put your work forward for comment, and that's all true, but equally, as commenters, what are we here for if not to present our own thoughts and ideas in a convincing way? If someone makes a comment in a way that they know is not going to be seriously considered by the person they're responding to, all they're doing is showboating for folks who already agree with them.

But then, if you are posting something in a forum where people can comment on what you wrote, are you really not asking for feedback?

[0] https://github.com/craigmichaelmartin/pure-orm

https://github.com/multiprocessio/datastation

some _person_

it's not just a software engineering problem, every one is susceptible to taking shortcuts in any walk of life: the shopkeeper knowingly stocking expired food, the hotel manager who doesnt clean their rooms, the contractor skimping on materials

finding the root cause and delivering a working solution for all these people will probably be a more social than technical challenge. personally i blame entropy.

There are 3 to 4 million devs in the US alone -- with a sample of that size, you'll get the full spectrum of people. Heck, you'd probably find some that like that the dislikes were removed. From their perspective, by blocking your extension they're actually making the world a better place.

It's shades of grey all the way down.

I think the more elegant fix would be to temper the downvotes depending on the context (e.g. reduce the impact of a sudden spike in increased viewing to downvote conversion).

Are you just mad that dislikes were removed from YouTube? I don't see what that has to do with any of those statements.

Pretty sure they're saying that the YT developers would break their cool hack if they knew about it, because they want to keep their jobs (eg, getting paid, or "making money"). Sounds like the OP wants to view all developers as adhering to some Platonic ideal version of a "hacker ethic" where they wouldn't do something like that for a reason as banal as money.

I can sympathise with this position, but I acknowledge the reality that - at the end of the day - people are usually going to prioritize buying food, paying rent, etc., over adherence to abstract ethical principles. That's unfortunate in many ways, but hunger is a powerful motivation.

Are you just mad that dislikes were removed from YouTube? I don't see what that has to do with any of those statements.

I get the impression that the OP thing was lamenting the YT thing both specifically and as an example of a general class of similar situations... places where you have to hold back from sharing a neat hack because if you shared it, somebody would come along and ruin it.

It's also naive to think that YouTube developers don't already know about said hacks / workarounds.

Naive, or just abstract? I think most of us can agree that at some level of abstraction we would prefer that people put ideals and principles over banal concerns like money. It simply happens to be the case that, as of today, we don't live in a world that makes it easy to live that way.

Let's also not get too caught up in this Youtube thing. If I'm interpreting this correctly, that was just an example of a more general idea, not the sole topic of discussion.

It's also naive to think that YouTube developers don't already know about said hacks / workarounds.

Sure, but that doesn't mean they're going to prioritize dealing with it, unless somebody calls attention to it by, for example, posting about it on HN. I think the OP has a valid point that sometimes people have some $THING they might sorta want to talk about, but ultimately decide not to post here, because undue attention could be detrimental to $THING.

If some of these workarounds are published and become popular, then there is a risk the original devs would shut it all down, so the optimal strategy is to fly under the radar and tell no one, thus maximizing benefit for yourself even though it’s clear others could potentially benefit.

I think it's not just software it's every industry. Companies are structured to bubble up any significant decision making to a few people at the top. Software was just the exception for a short while.

As far as dislikes, I've no reason to think that I KNOW what the 'true' dislike number is / should be or that somehow this hack provides the true value ... it just as easily could be something in use by the typical dislike mobs and etc...

It's YT's platform as far as I'm concerned, their platform to do with what they wish, I might disagree but I'm not going out of my way to hide things / not talk about things on here because someone might see it. One way or another YT is gonna do their thing for whatever reason anyway.

Side note, folks really upset about dislikes thinking fighting the man .. are unwittingly playing the man's game by worrying about dislikes on some website.

I used to play a drinking game with friends where we would read HN submission titles and try to guess how the top comment was going to criticize it.

HN is simply not the place to go to share new ideas, projects, or anything that might undermine the consensus opinion.

On the other hand, I find myself doing it. Take a look at the new tesla model S, a very interesting an innovative car and one of the quickest on the planet. But I can't help but talk about what I think is fatally flawed - the lack of dedicated physical controls and a non-round yoke steering wheel.

Almost every project that I do, is designed and supplied as a finished, released repo. Most are modules (as opposed to apps). I do have the source for several of my apps in the public domain.

It's never been a problem for me. Most of the modules I release are for my consumption. I don't really care if it gets starred or forked on GH. In fact, the less, the merrier. If others aren't counting on my utilities, then I can play around with them, if I need to.

Most of my work is of extremely high Quality. It's designed for serious developers (like me), that are interested in bottom-to-top native development. It's actually surprising how few people do that.

When I release a module, I liken it to having a child. It is now my Responsibility to maintain and care for it.

Of course. Do you think I'm going to identify such things here? That's no different than submitting them.

See also: https://en.wikipedia.org/wiki/Wikipedia:Don%27t_stuff_beans_...

First was a firefox plugin, and the first plugin I ever wrote. It basically bans some results from google. https://news.ycombinator.com/item?id=23295989

Second is my current moonshot I'm working on where I was expecting a lot of criticisms and negative comments, especially from programmers/devs in the AI space (Fully AI driven indoor farm, kind of deep mind for agriculture and understanding plants better than any human). But the largely positive feedback of the community was really energizing and uplifting.