[ncouture]

You're very right about everything you said.

However at the end of the day, what's important to me is to feel I've tried doing the right thing.

This means I can't do things conditionally or "only if I trust my manger won't take credit for it". If I want to be credited for my work, I feel that it's mostly my responsibility take credit for it.

It can be very difficult to change people, teams, processes, companies so I understand why we may want to get something out of trying hard to improve things we feel others should want to improve as well. It's not always as obvious as "a salary increase" or "public recognition", but employees who try to improve processes indicates to management they are interested in sharing their input and committed to making things better. This fosters credibility, and creates a more positive work environment.

Job hopping may often be easier but is often seen as a red flag by employers and it can make it difficult to build a strong, long-term career.

What is unfortunate in my opinion is working with developers unwilling to learn more about systems and infrastructure. With the rise of DevOps, it's often the norm that many developers don't know how to do some part of their job. As opposed to your comment this is not on the level of "developer who doesn't know how to code" but "developer who don't know how to work with the underlying systems, builds, deployment processes, and the underlying infrastructure powering their code".

When people are unwilling to learn from others, they are missing out on opportunities to grow and improve. This can lead to a feeling of being stuck in a rut, and can ultimately lead to dissatisfaction with one's job or career; as much for people who lack some expertise and are unwilling to learn, than for those who can help them increase their competence in this closely related field of work, who often end up doing most of the work in this field