My basic point is this, even those with the wrong mindset can be swayed with the right mindset, as long as it is sincere.
I always try to praise a person. But I also want to "reserve all rights" to say that a codebase is crap or a choice made in the past was evidently a bad choice.
Finding the balance to critique work that a person contributed to, without criticising that person itself, is hard. A true challenge, I found.
It becomes even harder if a project is Open Source and you truly feel you have to "warn" people against using a solution in certain cases. It then becomes really hard not to sound like a grumpy old neckbeard or someone with a grudge. I lately decided it is best to just shut up, and let people find out themselves; to let them fail, fall or possibly succeed and prove me wrong instead. I do see the arrogance of that too, though.
Criticizing the code itself (with useful feedback), and not the person who wrote it, gives them a chance to own up to it if they're comfortable with doing that. And if not, you're still able to improve the codebase without directly calling them out.
If they get pissy about it, that's on them.
A critical skill for a senior engineer in a team is to define and establish such standards for the team. Rather than reacting to each design/code review, taking the time to setup these process mechanisms is a lot more productive and healthy for everyone involved.
This requires strategic thinking (a skill that comes with practice) towards how you choose to spend your time at work to accomplish anything.
A lot of projects lack that "objective standards". I've been helping to solve exactly this. But code can be messy without having a clear defined "clean code" standard. And a project can perform horrible, without having minimum response times docutented.
Often my job was to define all those. And often those definitions already hit a nerve. When suddenly your code is marked as "far too tightly coupled" or "too complex: AB above 34" when you thought it was neat and smart code, that is confronting and, I've seen, is often felt as personal critique.
How did you go about doing that? (How did you warn others about an oss project, ... Maybe one/some project at GitHub?)
Maybe when someone somewhere asks why I don't want to include X-lib or Y-dependency, I'll explain why for this case its not a good choice.
Generally, I keep this to the consultancy-reports and on-premise discussions though.
I would have appreciated working with you/people who gave some critical thoughts to third party dependencies.
I hope that each time you go to a new employer, you try again and see if they're happy with getting such warnings
The pro-social way out of the prisoner's dilemma's shitty equilibrium requires deliberate effort to foster the sort of personal trust and collaboration-by-default attitude that makes the 8+ work hours of every weekday of most of our lives not suck.
And it makes people feel good, which is personally enough for me (while recognizing the privilege that lets me say I have enough).
I’d hate to work with such an individual; I’d avoid them like the plague.
To me “good culture” is the de-emphasis of these kinds of mindsets (and emphasis of the opposite). To the point where it’s justification for hire/fire.
Pointing that something is wrong won't fix it, and if in the meantime you manage to ruin relationships within your team you have actively made things worse just to pretend being a good leader, but just proving you are an awful person to work with (and at this point you might still be wrong about your claim on what's wrong).
But continuing these existing good behaviors is really important too. If you tell people what not to change, then they won't accidentally change the good stuff in their efforts to fix orthogonal things.
I delegated some areas during a big event and I took one of those persons asside because he was too rude.
He said that he pointed out mistakes ( which was correct, but they were new) and that they would remember it better if he was this direct. I just mentioned that he should not be this rude and just explain them what they did wrong and he adjusted. It was literally his mindset ( he adjusted that evening, not his mindset)
I have the displeasure of working with a team member who does the exact opposite: at every chance he gets, he expressed his displeasure regarding other team members to management. Once I confronted him about that behavior and he stated that those who fix problems get promoted while those who create them get passed over, and he believed that by pointing other people's flaws he would improve his chances of moving upward.
I firmly believe that's the main reason most people don't praise anyone else. If they do, they are calling out their competitor's positive contributions, while no one reciprocates in kind.