Live data from Hacker News

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

news.ycombinator.com

471–480 of 653 posts

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

#472
post #446

I don't know how healthy this is but: I haven't run into many people who are harder on my work than I am. I have an attitude that there's absolutely nothing I do that can't be improved. This may sound miserable on the surface, but for me it's actually quite freeing. It has the effect of making it easier to accept that things aren't actually going to be perfect (so it can help avoid the trap of over-engineering) and a…

Massively behind this sentiment. To be frank, thinking you can ever make something that is impossible to criticise to ego run rampant. OPs question shouldn't be "How do I deal with criticism" but "How do I tame my ego", and that's a topic with teachings as old as civilization itself.

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

#473
In some cases, you can preempt criticism by being critical of your own work first in a public manner, such as maybe calling out something that you anticipate another dev might not like and explaining why you did it that way. That said, you may just run into people who like to complain and nitpick, dealing with them is more about being mentally and emotionally prepared to stay calm and grounded and try to steer conversations to a productive place.

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

#475
I noticed that there's a huge difference between receiving criticism on something that is work in progress versus something I consider being "done".

When something is still a work in progress in my mind, it is much easier to have a positive attitude towards criticism and see it as something that helps me improve. There's something I can _do_ with the criticism in these cases.

However, when I consider something as done and it is criticized, I can get frustrated and defensive. It's a bigger mental leap that's necessary to make the criticism actionable.

The simple (though not easy) solution is to consider nothing as permanently done.

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

#477
I’d think of this as two issues, assuming we’re talking about constructive critiques:

(1) how do I not take snarky critiques of my work personally?

(2) how do I not take kind critiques of my work personally?

Issue 1 is often about understanding why the other person is snarky. Do they get this issue a lot? Do they realize they’re being snarky? Are they just a dick?

The goal here is to empathize so you can translate the feedback to issue 2.

Issue 2 is often about your own relationship with your work. Are you wedded to it, because it’s the creation of your own hands? Is everyone else too dumb to see why your solutions work? Are you in an area where the underlying issues are opaque or challenging?

The goal here is to be introspective + address why you have a gut reaction to the feedback. Eventually, you’re trying to get to a “reviewer and I against the problem” mindset.

All that said - sometimes it’s not a bad thing to take things personally. Recognizing when “feedback” is out of bounds is part of the process. Good luck!

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

#478
post #475

I noticed that there's a huge difference between receiving criticism on something that is work in progress versus something I consider being "done". When something is still a work in progress in my mind, it is much easier to have a positive attitude towards criticism and see it as something that helps me improve. There's something I can _do_ with the criticism in these cases. However, when I consider something as don…

Agreed. Unless you’re my PM. Then the requirements are DONE dammit

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

#480
It is very hard to do good code review. The reviewer is always missing context. It's easy to overly focus on style nits and not meaningful changes. This is exacerbated when PRs include a large number of changes.

Additionally, code review is the worst time to question decisions made by the developer. You have probably put a lot of work into your changes. Someone callously tossing a "why don't you do it this other way" into your PR feels like bullshit because it is. And again, larger PRs are going to have more (and lower quality) comments, which makes it easy to feel criticized or defensive. The parts you had the most trouble with are likely the parts that people are going to comment on most.

The solution to both of these is to try and break your work into the smallest chunks you can. This makes it easy to catch your own mistakes, as well as reducing the mental burden on the code reviewer. It gives you a chance to validate your strategy before you implement the whole thing. I've never been on a team that pushed back against the idea of splitting a large task into smaller ones.

As to when you do get called out on a mistake, it's ok to feel bad but recognize, people make mistakes. The person did you a favor by finding it in review vs finding out when bug reports start coming in. If it's a good catch, respond by saying "thanks for catching it." Nobody knows everything, nobody writes perfect code.

Post reply on HN