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

Anecdotally, I had the opposite experience!

> You'll find that the people that break down at the slightest criticism the most are those that were criticised the most as children as well. Those that had no room for being anything other than perfect. Where value was obtained from performance.

My childhood fits this.

> "Anti-fragile attitude" when it comes to criticism is not built by tolerance

I DID learn these by tolerance!

> self-acceptance and compassion. And these values are learned early on.

I learned these LATE on, in college. I feel like it's typical for a kid, but I was insecure and very much afraid of failure. But when I encountered sustained failure despite my best efforts, it pushed my "attached to performance" ego to the breaking point. That ego broken, I was forced to decoupled my sense of self worth from my performance. I didn't do it consciously, either; it sort of just happened one day. And I literally mean on a day. I felt it the day it happened. It felt like a weight had been lifted, and I found myself unable to care as much, just all of a sudden. I wondered if it was depression, but I felt happier than I ever felt before.

That nerfed my performance somewhat, since it's no longer driven by a frantic self-flagellatory imperative to prove my self-worth, but it also made my quality of life much higher, which I consider an easy trade.

I still care about what I do, and I very much still try to do a good job. I'm just not terrorized when I don't. I feel bad when I don't, but not "I'M A PIECE OF SHIT" bad. It's a more impersonal bad. It also allows me to sincerely welcome criticism; there's no sting to it at all unless I did something colossally stupid and/or the criticism is, like, downright verbally abusive or something (which it's never been so far :p).

I used to work in nuclear power which had probably the best culture of not taking things personally I have ever been a part of. The workers were mostly aligned with the idea that our job was primarily to be safe and secondarily to perform work. If something wasn't safe you were obligated, but also supported, to do so. The concept of making mistakes was reframed as a problem with process and not a personal failing of the person.

Process, not people. That concept has been a central driver of the culture I carry forward. If things are going wrong it is infinitely more productive to assume people want to succeed, but the process we have has prevented the outcome we want somehow. Even if sn individual made a mistake it is still possible to point to training, procedure, or even culture as being the real issue. This doesn't apply in cases of ignoring process or intentional incompetence, but that was very rare.

When people criticize me I am quick to try and focus on what could have been different about the process to lead to a better outcome or how I could have better managed expectations to reduce confusion. Of course I am in product management so managing expectations is what I do. So often disappointment and frustration come from a place of confusion. The more transparency someone has into why things happened the better they usually feel about the outcome.

TL;DR Focus not on yourself but the process that lead to the outcome. Mistakes are inevitable. Bad outcomes from mistakes only happen in poorly designed systems and processes.

My suggestion is to do more design work up front before touching code. Write up a plan in a drive document or an internal wiki tool, with a focus on capturing requirements, a high level description of your proposed solution, and detailed sections on the portions you anticipate to be complicated, controversial, or risky. Also include an "alternatives" section where you very briefly summarize technical approaches that you considered but ruled out.

That captures most of the high-value engineering work necessary to solve the problem, and you can move faster, unencumbered by programming languages, linters and toolchains because you're using freeform human communication. That document is allowed to be ugly.

Once you have an initial idea down, even if you don't like it yet, pass it around to your coworkers. Ask them for feedback on the design, especially the requirements, and ask them to help you brainstorm solutions to the parts you don't like. Your coworkers are going to naturally approach your document with a positive, progressive mindset. There's no risk of breaking things or stepping on toes. Chances are there will be design decisions they don't like, or have better ideas for how to do it. Since it's a freeform document, you can quickly rewrite stuff and tweak it until everyone's happy, or you can at least have the tough conversations to reach a compromise.

Once your coworkers have had a chance to provide feedback, then is the time to write code. Since you did that up-front work, you should be able to barf out the code 10x faster. You could even hand it off to someone else like an intern to barf out the code.

When the code goes through code review, it's your coworkers' jobs to be in a very conservative mindset, looking for regressions and maintenance pitfalls. You'll likely have a very different experience, though, because the code is now the manifestation of a previously agreed upon plan. It's simply an artifact. The lines of code are "cattle" to be slaughtered and consumed rather than "pets".

My usual response to this is: ask me in private or in a water cooler chat. I love to talk about programming. And I love learning how others approach things as well.

If the level of trust in a team is high enough that asking such questions is genuinely considered honest and useful then most people ought not to be feeling bad about honest mistakes or characterize feedback as, "snarky," and feeling anger, shame, etc after a code review. If people like these kinds of questions and it helps the team then maybe it should be in the code review guidelines.

For me, I have a hard enough time discerning the intentions of other people. Guidelines remove some of that ambiguity up front so that I can safely assume people are being genuine and it is obvious to everyone else, and me, when they're not.

However, the spirit of the idea is that code reviews shouldn't be leaving you feeling bad about yourself and the mistakes you've made. That could be a you problem but I think it's more common for us to self-doubt than to realize that perhaps the problem may lie with other people. Imposter syndrome, DK, etc, etc all seem to run rampant.