My best managers weren't ones who knew every detail of each project and could give unsolicited effective advice. They were ones to whom I could tell what was going on on my project, could ask for help, could tell them what I needed, and then rely on them to follow through on helping make that happen. Sometimes that was needing more time for a deadline, sometimes it was needing a mediation in a complicated relationship with another team, and sometimes it was using manager clout to go escalate a request for compute resources.
In any case, two-way communication is going to create a more effective relationship than expecting your manager to simply _know_ what you need.
Where did you get this idea?
I agree you should not try to push through a bad situation, it really depends on the people involved and it's hard to give generic advice.
Integrity is who you are when nobody is looking, and all that.
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