Exactly this experience happens in big teams internally as well.

It works like this according to my experience: You see a problem before it really does financial harm to the company. You start developing a solution. You expect to get rewarded with prices, raises, titles and public encouragement, because you solved the problem before anybody even saw it.

But instead this will happen: The employees who run into the problem first and therefore would be the one who suffer from it, find that your solution may be an answer. But instead of making it work they find ways to complain about it publicly. Since management hasn't yet realized that there is a problem, they just hear that you are not doing your job and put pressure on you to fix all the bugs, because of your bugs nobody else can work, so it seems.

This is not stupid by the other people or by accident. The moment they have found a way to complain about you it doesn't matter anymore if the task will be successful or not, since a failure wouldn't be blamed on them anymore as well. Everybody knows that the bugs are your fault, right?

In this regard open source seems less harmful to me. In open source at least there is no boss who can push you to solve the bugs, or fire you if you don't.

I had somewhat a similar experience in a previous job. Automated a lot of stuff to speed up our workflow. Never got anything material out of it (bonus/raise, etc). The reward was an expectation to increase our output ("Now that it takes half the time to do X, everyone should double their output.") The other reward was maintaining my code while expected to double the output. At one point the manager made it clear I would not get a promotion based on this.

I left, and in my next job I tested the waters a little to see if they'd value such contributions. They did, and so I happily continue to make them. Had they not, I would have stopped quickly and moved on to another job. As an engineer, my job is to solve problems that need to be solved. I could be like everyone else and just go along with it (not solve them and maintain the status quo), but that's not why I became an engineer.

Companies are generally hierarchical systems. By developing the solution on your own initiative, you bypassed that. You should never expect a good reaction from a social system when you break its rules, even if for its own benefit.

One thing that's so confounding about this is that so many hierarchical organizations (companies, non-profits, universities, etc) encourage "initiative", but then when you take that initiative, you may/often catch shit for it, even if you're doing the right thing from an objective point of view. Of course, there are complex politics at play and the reaction you get depends on largely on "who you know" and if you effectively kiss ass.

There was a semi-famous author in my city who did that on a personal level: he would ask his friends to keep part of his paycheck until a certain day, and not give it to him even if he asked, since he knew he'd misspend it all (often by just being generous to friends and people in need).

More than once, not only did he ask for the money before the date, as upon being denied, he went around in coffeeshops and bars defaming them, telling people they'd stolen from him, etc.

If even individuals can be this inconsistent, we shouldn't be surprised that companies - composed of multiple private interests, as many as their employees and board members - exhibit similar behaviors.

It is like a gambling addict who enrolls themself voluntarily on a gambling ban list and then does everything possible to get back into the casino.

I once enabled noprocrast here, that was hell

This was also hard to understand for me. But think about all the benefits people in higher positions have if people in lower positions take initiative. The higher ups can reap most of the rewards of successes while blaming all failures on the initiating people. Of course they like it if you offer such gifts for them.

The way to handle this is to develop the solution, but don't reveal or pitch it yet. Instead, position yourself to hear about it when people start recognizing the problem and start looking for a solution. Then, be the one to solve their problems, and that's the kind of initiative that gets rewarded. Success depends on not just having the solution to a problem, but having it at the right time as well, when the market is ready to adopt it.

I sympathise, but there is a flip-side.

Code bases, get full of half-arsed framekworks and automation tools that nominally solve all your problems, but don't, either because they address the wrong issue, or because bugs prevent them from doing even the nominal job. Yet these half-working things can become the required internal standard that teams have to adopt against their wishes. They will not be forgiving when the maintainers start ignoring bug reports.

Now this is fundamentally a management failure: pushing a solution without knowing its limits or counting the cost of backing it up and compensating the maintainers. But as engineers we tend to be complicit, because when we make a new shiny thing, we also want to push it and don't want to tell mangement that it will really cost three times more than they were hoping.

I wonder what is the best strategy to this problem:

You take the initiative and develop a new feature, automate a task, increase productivity, optimise costs, or increase revenue. You would like to reap the benfits (promition, bonus) but not increase your workload or take the blame for bugs that are unavoidable in the new tech.

1. Automate tasks and keep it to yourself or your immediate team and hopefully work less.

2. Talk to your boss before you reveal your solution, such that he will 'discover' it and let it be his idea. Depending on your idea, this might be hard.

Any other ideas?

Develop your solution but don't actually implement it. When the problem is discussed offer to fix it in a short amount of time (faster then the actual time). Everybody will remember you as the one being most profitable for the company.

In big companies (in my experience), projects are owned and funded, or they don't really exist. In the case of a side project that doesn't get official support, there is a perfect response pre-made for this situation: "Why are you depending on an unsupported package?"

Yup I agree, working in a product team however one thing I will consider a red flag with projects is internal costings (i.e. having to "hire" devs from other teams for a certain dollar amount), however I understand the importance of getting other teams to "buy in"

Yeah, this is my experience as well

Before open sourcing, I have that anxiety that people will look at my shitty code and judge.

Nobody really looks at the code in reality. People just come, write some terribly written bug report, and then they write "+1" in github issues.

Until your code gets linked on HN or Reddit where people will then read the code and then proclaim that the person who created it must be dumb because of all of the obvious mistakes they made (generally ignoring the reasons for some of those choices as bad reasons).

That's what is pushing me away from releasing code to the public. It's really crushing to my self worth as a developer to feel good about a project only to be told how awful it is and how it's broken by design.

I had code on HN (on a different handle) and really, people never nitpicked code. Nobody cares about that one misnamed function or that global variable or that useless abstraction layer.

People, however, do like the one-note replies. "Why isn't this in Rust instead." "Why isn't the license GPL instead of MIT" (or vice versa). "The name is immature." "Will this be on Mac OS X too? Why not?"

Why would you care what others think about your code? Nobody knows anything in this industry. There is so little important criticism, that even finding it if you really want to is super hard.

I know that on the surface, but it does something to me as a person when I see it.

I can tell myself it doesn't matter I can tell myself that they don't know the details or the trade offs that were made, but regardless it still takes the steam out of my willingness to work on it.

It helps me to remember the following:

- I am not my work.

- All software sucks. Some suck less than others.

- I have simultaneously been catastrophically wrong and full of confidence in the past. Be open minded to the possibility there's a very different way to do things that will make you a better professional. Be similarly open to the possibility the other guy is full of shit.

- Developing a thick skin will make your life (in general) easier. It's better to do it in a short, intense period of time than prolonging the pain over decades of your life.

Did you make these discoveries when someone complained about "mixed casing" in your code? :-)

Seriously though, well put! Thanks for the reminder.

I found the opposite to be true. I am often surprised at how friendly and constructive comments on my projects are. After sharing them on /r/webdev, /r/react, or HN, I've had multiple messages with people helping me fix bugs, teaching me how to do things better, or just encouraging me to do more.

You are lucky. Some projects have difficulty because everyone wants to use it but no one wants to contribute to it. The inbox of the maintainers may be full filled with bug reports and they have to spend one or two hours to handle these problems. They are tired.

Why would others care about his/her code being trashed publicly? Because we are all human beings. We all have feelings. Some of us are tougher than others emotionally but even those of us who don't give AF what others think feel something when hordes of anonymous master coder warriors on the net trash your work. It's also a reason people like joe rogan don't even read social media anymore because of all the hate generated by throngs of basement dwellers. It takes a toll on you to get a tsunami of criticism from internet trolls and those who just love to tear others down sadly. Why would anyone want to inflict that on themselves?

It is 100% same in my case..

This matches my experience. Even now, depending on the day, I might be looking at around 30-50 emails of varying, usually depressingly low quality per day. I've had some relatively successful one man projects in the past and at peak popularity it would take me several hours per day to sift through everything.

Care to share the python project? Asking as someone who's made PRs to CPython's core in the past

Not OP, but I believe they're referencing py-lmdb. https://github.com/dw/py-lmdb/

> None of the regular project users have stepped up

Most projects' development processes are under-documented, even healthy projects and those run by people not looking to get out. This may be the case with yours.

Have you written up a short description of your practices and the things that a maintenance takeover would entail?

Sorry, I've had a personal thing come up. I'll help you out soon.

Small world.

What's the project, out of interest?