Personally, I try to detach it from myself and think in term of process, even if they are just internal processes (as in processes I created for myself).
Why was this bug not prevented? Did I follow the processes? If yes, why did they fail, and how can I change them not to fail next time? If not, why did I not follow them? How can I ensure that this will not happen again?
Also, can I share my experience? Can I learn from someone else experience? I think it's very good to say "I did this and that, which I thought would be enough, but it wasn't, how do you guys do it?".
Not saying it's perfect, and I always feel bad whenever there's a bug in code I wrote, but I'd rather hear about it, if only just to try to reduce the amount of time this happens in the future.
This is all going to vary from workplace to workplace, but:
1. Proactively ask individuals for code review.
2. Thank people, visibly and publicly, when they point out mistakes or offer good suggestions.
3. Be an example when you leave critiques; accept that beyond some agreed-on code standards, some things are subjective. Just because you wouldn't write code in a certain way doesn't mean the way they've written it is wrong.
doesnt matter how wrong or personally based the attack/criticism is. The more extreme the situation the more important it is to keep to the plan.
the lessons learned will cover all of existance as you will learn more about how people model the world, problems and solutions beyond the specifics of the problem at hand.
*if doing this drains you make a change of environment (e.g. job), however i find that the discussions you have like this change other peoples thinking more effectively, so its also how you sew the seeds of cultural change.
You can see from the other comments that people like prescriptive actions that anybody can take. It's a lot harder to accept that you might have some behavioral or mental issues that you need to dig into which would then make all of these behaviors natural. Forcing yourself to be a steel man is pretending. Becoming a steel man is much harder but is possible for those who willingly seek treatment. If you're willing to ask this question it means you are a good candidate for treatment. Good luck.
I like to think of criticism as scientific peer review. The purpose of that is not to criticise the person, but to strengthen the validity of their research by eliminating any remaining errors they may have missed.
Your peers aren't harming you by finding fault, they're strengthening your position by doing so.
I personally hate it when a bug slips through to production, and I always profusely thank anyone that spots one before it does. Or after. Whatever, as long as it gets fixed...
Why was this bug not prevented? Did I follow the processes? If yes, why did they fail, and how can I change them not to fail next time? If not, why did I not follow them? How can I ensure that this will not happen again?
Also, can I share my experience? Can I learn from someone else experience? I think it's very good to say "I did this and that, which I thought would be enough, but it wasn't, how do you guys do it?".
Not saying it's perfect, and I always feel bad whenever there's a bug in code I wrote, but I'd rather hear about it, if only just to try to reduce the amount of time this happens in the future.