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

Of course I'll be wrong. But its best to learn where I'm wrong so I'll be aware for next time. Learning why I'm wrong is the take away, not that I was bad.

Now, what we should realize about the code isn't the thing of value. It's what the code does and how it does it, that is the runtime output and the ability to express the intent to produce that output to a programmer who hasn't seen the output or the code before or in a long time.

Criticism is the best opportunity to improve those aspects of the code you write. So it should be of equal value to you as the lines of code the criticism is addressing.

Not all criticism is valid, even well-intentioned constructive criticism. Experience teaches you which critiques to accept and which to reject.

The only way to gain that experience is to solicit criticism from others, and give it to others.

No, we are not just our code, but our artifacts are a part of us, as we are a part of them. So we should be kind when giving criticism and gracious when receiving it. Because what we choose to do with our time matters.

That's a little of what I was getting at with some of the points above. Tons of criticism is just plain subjective. How do you evaluate the validity of someone else's subjective decision? The ultimate answer is that you can't if your response to it is to flip the table and leave the room.

>There is an issue with some people who are just not structurally fit for that sort of thing, where the slightest criticism can make them collapse into a heap of self-loathing and depression.

I agree, but I think that in and of itself is a bit of a different problem. A key aspect of the modern human condition is being able to deal with criticism. If the slightest bit of it will "make you collapse" then that's a strong indication that you need some professional help to learn how to deal and process things.

>Discretion and discernment are important so that you don't break a fellow human. So the flip side is that being a part of critique juries is also training in how to give criticism, which is an important skill in and of itself.

I don't disagree that teaching people how to criticize will help have that criticism be better structured, less aggressive, and more constructive overall, but the reality is that we can't expect everyone to have "the proper training". There absolutely were jurors that I had that were more about tearing you down than trying to help improve. Dealing with those people was a learning process in and of themselves.

>And programmers tend to spend a lot of time up in their heads. And they tend to be rather blunt about their opinions. Getting some time in the reviewer and reviewee seat is useful.

This points to the social nature of giving and receiving criticism. There needs to be emotional awareness from both perspectives. Programmers, as a generalization, tend to be more anti-social than other professions. A key aspect of social interactions is empathy; being able to see things from others' perspectives. When I look back at some of poorest delivered criticisms or responses to criticisms I've experienced in my professional career, they've come from the most anti-social developers.

Bluntness can have two interpretations, being straight to the point and/or not going into details. "This is poorly structured" is blunt, but doesn't attack or make things personal. "This is crap" is just as blunt, but has a far more negative connotation and interpretation to it. Neither is all that great of a criticism if they're not expanded on or explained.

What you are doing is a higher goal than a PR, and detaching yourself from the minor details allows you to achieve this with greater flexibility and skill in the long term.

You have to take steps back and see subsequent bigger pictures and see what you’re doing within the context of a product, a job, a pattern of self-improvement, a fulfilling life.