Ask HN: How do you not take criticism of your work personally?

I find that I naturally frame myself reading comments of my work as being inherently "with" the person. Think of it like watching a movie with someone, you both can comment on the movie you're seeing, and you naturally see yourself either agreeing with their critique or forming your own critique based on it.

In the same way, detach yourself from the work, and instead view your work on equal footing with your reviewers - this naturally leads to a more objective view for everyone involved. Reply not to their criticisms of _you_ but to whether you agree objectively or not, or perhaps suggest a different way they can look at the work. Oftentimes, after reading someone else's critique I can be self-critical in a way I wasn't before and it will lead to me refactoring a bit in response to my new perspective on my work, instead of completely taking their critique at face value. Use it as a perspective shift, but don't take this method as a way to lower your self confidence and give in to critical feedback.

Now I'll admit what I have more problems with is when someone clearly doesn't "get it". I'll bend over backwards trying to explain my rationale, when often the right thing to do is to try and understand what about my content caused them to be confused. Now of course, some people just plain don't get it right away and you should always feel free to defend your ideas.

As for snark.. defuse with humor. It's not always intentional, I've unintentionally come across this way (if you haven't you're probably holding in too much feedback!) so feel free to quip but don't go tit-for-tat. Try and cut through to the core of their feeling about *the work* (read: not you) and address that instead.

I view PRs as a kind of luxury. At many corps the deadline is yesterday and any single mistake you make ends up in production without reviewing or testing.

If someone disagrees with anything in the code, you can point them either to a requirement that would have to change if it were done differently, or else some documented best practice (whether in-house or some famous external one) would be violated.

Have a reason for everything. Why is there a linear search in that function? Because the number of items is at most ten, and not expected to ever exceed around fifteen; moreover, the function is called only a dozen times, on first boot after a firmware upgrade.

Also, be the most stern critic you can be, of your own code, criticize it yourself and fix everything, so you don't leave much for anyone else.

Absolutely, but:

1) not all of that value, just the value as someone who does that work. I mean, it would be crazy to think that you have no value as a dad to your three-year-old because you made some crap code design.

2) not for all possible values of "someone else". Just those someone else who have a clue about the work, and make specific, objective criticisms that are verifiably true, and who understand the context of the work: what are its requirements and non-requirements, including constraints.

3) I don't necessarily want someone else to think everything I make is of high quality; however, the right somebodies should more or less agree with me about the quality. If I make something and think it is of medium quality (for some justifiable economic reasons), then if someone thinks it is of great quality, I will regard him as a fool; but if someone thinks it is of garbage quality, I will wonder whether I might not be a fool. Ideally, we should be of one mind with everyone who understands the problem and the work. If the work is mediocre, everyone (including the author) should find it so based on some objective criteria. Everyone who understands the economic reasons for why it was made mediocre should ideally agree with that also. "Ah, I see; I would have done it the same with regard to that purpose and those requirements."