For some of the points, I would add - be that way, but don't automatically assume others will as well.
Yes, you shouldn't "take criticism or negative feedback as a personal attack". But the robustness principle applies here: be conservative in what you do, and be liberal in what you accept from others.
Other co-workers are only humans, and they may not be able to accept dry criticism. Yes they shouldn't be attached to their code, but they always will. We naturally are kind of attached to something into which we've invested hours of work, even if we know it's better not to. And you're particularly likely to be perceived as aggressive or confrontational if you criticize in writing (as in in code review). It's easy to fall into the Sheldon Cooper syndrome, whereby in your mind you're only pointing out facts, while you come across as a douche to the people around you.
For that reason I would recommend some extent of cautiousness in critizing others.
Never assume bad intentions or incompetence by default. My key phrase in code review, whenever I suggest what seems to be a clearly superior alternative, is: "what am I missing?". By stressing that I understood they could have had some valid reasons for what they did, I make the criticism much easier to swallow. And guess what - once in a while I am indeed missing something :) And then I'm quite glad I spoke out with some reserve.
Sweeten your criticism up with a bit of praise. For every 10 critical remarks I leave in a code review, I try to find something that I like and point it out. It costs nothing, and it creates a more friendly atmosphere.
Another keyword that I like is "we". "I'm afraid you're making this function too complex, you really shouldn't be mixing async logic with business logic here". No: "Aren't we making this function too complex? We shouldn't be mixing..." - and so on, you get the idea. It costs absolutely nothing, and it communicates a totally different approach. Collaborative, non-confrontational, goal-oriented and helping to detach everyone from the code they wrote through positive, constructive mindset.
Thank you for writing these down Konrad. All of these make absolute sense and are very vital traits to learn to promote an environment where nobody feels attacked, questioned, or not trusted enough!
Students coming from cut throat academia competition environment should understand these as soon as they can!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
For some of the points, I would add - be that way, but don't automatically assume others will as well.
Yes, you shouldn't "take criticism or negative feedback as a personal attack". But the robustness principle applies here: be conservative in what you do, and be liberal in what you accept from others.
Other co-workers are only humans, and they may not be able to accept dry criticism. Yes they shouldn't be attached to their code, but they always will. We naturally are kind of attached to something into which we've invested hours of work, even if we know it's better not to. And you're particularly likely to be perceived as aggressive or confrontational if you criticize in writing (as in in code review). It's easy to fall into the Sheldon Cooper syndrome, whereby in your mind you're only pointing out facts, while you come across as a douche to the people around you.
For that reason I would recommend some extent of cautiousness in critizing others.
Never assume bad intentions or incompetence by default. My key phrase in code review, whenever I suggest what seems to be a clearly superior alternative, is: "what am I missing?". By stressing that I understood they could have had some valid reasons for what they did, I make the criticism much easier to swallow. And guess what - once in a while I am indeed missing something :) And then I'm quite glad I spoke out with some reserve.
Sweeten your criticism up with a bit of praise. For every 10 critical remarks I leave in a code review, I try to find something that I like and point it out. It costs nothing, and it creates a more friendly atmosphere.
Another keyword that I like is "we". "I'm afraid you're making this function too complex, you really shouldn't be mixing async logic with business logic here". No: "Aren't we making this function too complex? We shouldn't be mixing..." - and so on, you get the idea. It costs absolutely nothing, and it communicates a totally different approach. Collaborative, non-confrontational, goal-oriented and helping to detach everyone from the code they wrote through positive, constructive mindset.
Just my two pennies.
Thank you for writing these down Konrad. All of these make absolute sense and are very vital traits to learn to promote an environment where nobody feels attacked, questioned, or not trusted enough!
Students coming from cut throat academia competition environment should understand these as soon as they can!