On the other hand, in this industry often what one engineer identifies as a mistake another might be neutral toward or identify as a best practice/correct.
Our industry doesn't have many standards, and it's not nearly as objective as some think. And often criticism isn't intended to improve an outcome: it's intended to bring others' in line with the critic's view of how it should be done.
All this to say, I'd just add to your comment that one must also develop the ability to discern when a critic is identifying a true mistake and when they are simply parroting a fad or injecting their subjective beliefs into the review.
Excellent response. By and large the field is a cargo cult where the members are particularly adept at constructing straw man and false equivalency arguments to support specific preferences which are not rooted in anything resembling objectivity. See "Clean Code".
While it is hard to hear criticism directed at you personally, or at something you have put your heart and soul into developing; discerning between constructive criticism and 'knee-jerk responses' is critical.
Maturity means that you can accept criticism that is intended to help you improve. Making you aware of an issue or directing you towards a better solution can make your code or product a better one.
Simple insults thrown from the 'peanut gallery' should just be ignored. If you have built something using a particular language or framework on a particular platform; you should expect those who don't like those things to throw in their two cents without even trying to understand the problem you are trying to solve.
I feel like I'm constantly fighting this with my manager at my current company. I receive a lot of feedback along the lines of, "well every other company I've worked for did it X way." For example deployments: company policy is that anyone can deploy any service from master at anytime, so if you merge your code into master, you're saying "this code is ready for production." My manager kept telling "we" should fix that because every other company he worked for deployed from staging into production.
I've found managing situations like this to be the hallmark of a good architect / high-level engineer. I really admire people who are able to think quickly on their feet and push back against people who push for ignorant or unnecessary changes. And it is something I am not good at.
I've taken to silently fixing peoples' mistakes as to avoid these kinds of discussions. While I'd really like to say, our architecture did not force you to push broken code into master hours before you went on vacation, my (agreeable) personality prevents that.
As an engineering leader I always insist that everyone follows the "ice cream" rule in any debate or discussion about how something should be done. Only technical merit counts. Never personal taste.
Whether it is a design pattern, deployment strategy, or choice of language, if your argument has no technical advantage then you are just expressing your taste preference. This is where someone will likely call you out by asking, "are we discussing technology or ice cream flavors?"
Our industry doesn't have many standards, and it's not nearly as objective as some think. And often criticism isn't intended to improve an outcome: it's intended to bring others' in line with the critic's view of how it should be done.
All this to say, I'd just add to your comment that one must also develop the ability to discern when a critic is identifying a true mistake and when they are simply parroting a fad or injecting their subjective beliefs into the review.