Hacker News Reader

Comment by rualca | Hacker News Reader

> I don’t think people express these things nearly as often as they feel them, and I expect that many of the positive things that do end up communicated have another motive behind them.

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.

View on HN

This is a terrible mindset to have. When I was a manager I took every opportunity to praise my employees (with meaningful compliments and feedback) and discouraged negativity. During a management team meeting I even stood against the others on promoting someone because he was always negative and I pointed out how inefficient his coworkers were around him and that he would only continue that, it didn't matter how good he was himself at the job, he needed to be encouraged to change for the better. After working with him for a while and helping him see how he was hurting others and himself, he changed his mindset, and was later promoted, I continued to coach him even after I left that location.

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 hear you. But having once worked with team-members who take critique at anything, personally, I feel there is more to this.

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.

> if a project is Open Source and you truly feel you have to "warn" people against using [it]

How did you go about doing that? (How did you warn others about an oss project, ... Maybe one/some project at GitHub?)

I don't do that in public.

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.

Thanks for explaining

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

Edit: now i noticed you've founded your own company

I've found that if part of a codebase is truly shoddy or just plain badly written, the developer who wrote it generally knows how bad it is, or at least that it's not up to snuff.

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.

For someone to see your criticism as objective, the objective standard should be established ahead of time. For design/code reviews this means having coding standards/guidelines and training everyone to stick to them – rules of the game are known ahead of time to all participants. Then it is much easier to convince someone that it is objective feedback.

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.

> as objective, the objective standard should be established ahead of time.

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.

I've had peers like that too. I'm sad at the proliferation of zero-sum thinking. It's like a prisoner's dilemma. The equilibrium state is competition, but collaboration gets us all ahead in a non-zero-sum way. Or, if you really do see it all as zero sum, there's still an analytical way out. Just take the long view. Collaboration will get our group ahead of the group who competes for the smallest things. Hyperbolically, we'd all rather be a low level IC at early my-shares-will-be-worth-infinity Google than be a VP at an imploding firm.

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).

It’s possible this individual has a personal experience or upbringing where reciprocal behaviors were not respected. It’s possible he’s correct in certain workplaces.

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.

Bad things and behaviours should be called out in order to actively fix them instead of just waiting on that they are magically fixed. But this must be done in a constructive way.

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).

Even if you don't accidentally ruin relationships, you might ruin the good behavior alongside the bad. I'm a big fan of a feedback system I've heard called "stop start continue." Stopping these bad behaviors, and starting these good behaviors are in the same vein of fixing bad things.

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 can confirm that some people think like this ( not me).

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)

This reflects just as badly on the org's leadership, as it does on the individual. Managers and other leaders need to give people a talking to, when they engage in toxic behavior. And they need to set a good example by promoting people who are good teammates. Do this consistently, and people will change their behavior for the better.

He's doing you a favor. Now you know that if he gets promoted faster than you or your co-workers, it's probably time to find a better company (or a better team, if that's an option).

I wonder if the review system is stack ranked?

Reply on news.ycombinator.com