I agree it's often difficult, but I think it's possible to balance honesty with humility and being a so-called team player.
For example, if you see something that's sloppy [1], your honest assessment will likely help both the coder and the manager. But you do have to temper your language, and sandwich the criticism in something that won't make the person interpret it as "you're sloppy/stupid" or "you don't deserve to work here".
The additional problem is: you have to test it with baby steps. If a coder/manager can't take any feedback [2], not even the friendliest suggestion, you have to pick whether to (1) slowly train each other to communicate better, or (2) leave (it alone).
But ultimately (IMO), it's not worth training yourself to be less honest or dishonest. You risk losing the ability to do your best among other smart, honest and feedback-accepting people, or being an honest and feedback-accepting manager/employer yourself [3].
[1] Like many blocks of copy-pasted code, or massive scripts with no separation of concerns, which can really grind my gears.
[2] I've personally had a few discussions with peers and leads in teams who would get defensive, or interpret my feedback as politicking, even in a cooperative environment, and I didn't love that. But I also didn't love getting (what seemed as) "holier than thou" evals in (what I saw as) more competitive environments. So, maybe my cooperative is another's competitive, and vice versa.
[3] Because you can easily get used to a skewed or toxic environment, and accidentally spread that toxicity to others, or unintentionally be seen as toxic yourself.
> your honest assessment will likely help both the coder and the manager
While I'd like this to be always true, there will be cultures and even individual egos for which this will never be true.
Someone who's considered a senior dev in the org might dislike your assessment (regardless of what external resources and industry practices and any number of people's experiences say) and might turn your suggestions for how to make their code a bit better into a bikeshedding argument until either one of you tires out and gives up (no relation to which opinion is even right or what's best) or the manager gets pissed off at the both of you and has to intervene (not necessarily thinking badly of you) and the traditional methods like "pulling rank" wouldn't work either if it's a senior engineer. Even if you do everything right in how you approach it and frame it positively and everything else.
In part, this might be because there's no one set of guidelines for "this is what good code looks like", especially because of how fast moving and disjointed and underregulated the whole craft is (might settle down in a century idk). It might also be because that mess leads to vastly different opinions on what's good (e.g. how some people take SOLID/DRY as gospel, others don't, to the point where WET is a thing). And some people just don't care and don't see things the way you do.
Concrete example: once saw a bit of code that had nested service calls. Suggested to the person that this will lead to the N+1 problem in database interaction. They said that it's okay because the other code is written like that in the app already and that this code is easier to reason about. A month later I had to actually show them cache hit/miss statistics after implementing caching as a band-aid on top of the nested code because there were deadlines and nobody could rewrite the whole thing as a DB view. In that particular case, there wasn't even mean exchanges or whatever, just endless bikeshedding about whether something is needed or not that lead nowhere, even when graphs and data were presented by me.
Same for opinions on how much logging or code comments should there be, stuff like dynamic SQL generation vs DB views and a bunch of more nebulous things, though often with a quality of life impact instead of something so concrete as above, where pages started taking 20-30 seconds to load once the DB was properly populated with a lot of data.
So yeah, absolutely do your best effort and try to orient yourself towards open minded egoless developers in a cooperative environment. But sometimes that's not what life will give you and you might just realize "hey, naah, person X is the problem 100% here but it might be possible that I cannot do anything about it in this environment". I've also been person X, of course, but in general I think more honesty would be good.
Like figuring out why our national e-health project failed so badly as it did and putting the people responsible for the failure in jail after a proper root cause analysis is done, if they didn't seek proper remedies in an adequate amount of time: https://www-lsm-lv.translate.goog/raksts/zinas/latvija/09.04...
For example, if you see something that's sloppy [1], your honest assessment will likely help both the coder and the manager. But you do have to temper your language, and sandwich the criticism in something that won't make the person interpret it as "you're sloppy/stupid" or "you don't deserve to work here".
The additional problem is: you have to test it with baby steps. If a coder/manager can't take any feedback [2], not even the friendliest suggestion, you have to pick whether to (1) slowly train each other to communicate better, or (2) leave (it alone).
But ultimately (IMO), it's not worth training yourself to be less honest or dishonest. You risk losing the ability to do your best among other smart, honest and feedback-accepting people, or being an honest and feedback-accepting manager/employer yourself [3].
[1] Like many blocks of copy-pasted code, or massive scripts with no separation of concerns, which can really grind my gears.
[2] I've personally had a few discussions with peers and leads in teams who would get defensive, or interpret my feedback as politicking, even in a cooperative environment, and I didn't love that. But I also didn't love getting (what seemed as) "holier than thou" evals in (what I saw as) more competitive environments. So, maybe my cooperative is another's competitive, and vice versa.
[3] Because you can easily get used to a skewed or toxic environment, and accidentally spread that toxicity to others, or unintentionally be seen as toxic yourself.