Kudos on the realisation and desire to improve. There are a couple of tricks you can use, especially when it’s asynchronous textual communication:

Assume positive intentions from the other person. Imagine them as having written with a genuine smile on their faces. Don’t think of it as them versus you, but you and them together against the problem. That defaults ambiguity to the more pleasant side and allows you to reply in a kind manner in turn. In general you get out of a conversation what you put into it, so add kindness.

That doesn’t mean you have to take abuse. But even if someone is unambiguously disrespectful (e.g. name calling) you can generally be respectful when pointing that out or simply not respond. Instead of wasting brain cycles getting more angry as you write the perfect zinger, let it go and you’ll forget about it soon enough. Focus on feeling better, never on making the other person feel worse.

If you do have to reply, don’t do so immediately. Let it marinate and respond when your initial feeling has subsided. That allows you to get some emotional distance between yourself and your work, thus seeing (and fixing) the problem in the thing not yourself. Waiting has the secondary effect that another person may reply in the interim, shifting the burden away.

When you feel bad, stop to think. Observe your own reaction and calmly try to realise why you’re feeling that way and what’s your goal. The introspection alone can make you see that the situation is unimportant and thus taking it personally is disproportionate.

The first few times might be hard but eventually it becomes second nature as you adapt and find the approach that works best for you.

I don't have great advice. This is just how I think about it:

Nobody is perfect.

I stopped taking it personally after working on an app about 15 years ago. I was reading the code and had an epiphany: it was buggy as shit. Less experienced me probably thought it was fine. But if timings were just right, there were some bugs that would cause all sorts of errors.

But they hadn't ever happened, despite the system running for 3 years at about 10k requests handled per second. So, did the bug matter? I dunno. I fixed it, sure. But it gave me a new outlook. It's impossible to avoid all mistakes. So try your best, and don't beat yourself up over the ones you miss.

I work in consulting; everything I do I do for the customer and to improve their codebase. I often see a lot of terrible code. I change it and try to educate the coder who was responsible. When I get comments on my code I will always assume that I am wrong. Not because I am bad but because I am not that long with the company. I am missing the domain knowledge, ways of working, standards and all that. When I do get responses that "this does not work" I ask the person why he thinks that is so. Often it is a misunderstanding on how they think that API works it is not very often that I am wrong but I do not always assume that I am better.

Since I have been working in this manner people are more open to changes themselfs. It works both ways.

Are you a salaried / wage-earning employee?

If so, you may find it helpful to remember that the code you are working on does not belong to you, it belongs to the company/shareholders, and your job is to make it do what they want, more or less how they want.

That doesn't mean you have to do anything that is dumb, or not in the best interests of the company, but if someone asks you to do something that is dumb or not in the bests interests of the company, you may have to explain (very clearly, and often repeatedly) why it is not in the best interests of the company, and in doing so you may find that you had imperfect information about all of the relevant stakeholders and requirements.

Failure to remember this may result in being reminded the hard way, by being terminated / laid off, managed out.

Conversely, if you have great ideas and want to control everything, feel free to start your _own_ company, find your own clients, etc.

You've got some good advice already, but one that I'll add here is adopting the principle of charity [0]. Every time someone talks to you, interpret their words in the way that is most favorable to their argument and your mutual interactions. This assumption goes a long way to short-circuiting any negative thoughts you might have about their intentions.

For example, if there seem to be two interpretations of a comment on a PR, one that is genuine and one that is snarky, assume they were genuinely trying to help and reject the snarky version. This is easier said than done, but it's a useful skill to practice.

[0]: https://en.m.wikipedia.org/wiki/Principle_of_charity

I had similar problem early in my career. I improved myself by applying the mix of three:

1. If the change requested was not major I was making mental push to agree and just do it, in many cases comments were not about the very substance of what I was working on but they were sliding on the surface

2. I was learning to read my work and see if reviewer is actually right, as I'm not a genius and there are times I get something wrong

3. I was learning 'the art of not giving a f*ck', well, sometimes this is what you need to do to keep sane :)

Personally I never cared about it. The only goal I have is whether it's right on pointing to the direction of work better(which in turn makes me more money).

If it's point out something that can be done better. I can take it regardless how it's phrased. That is the only thing on my mind when I am working

It's hard because if you care about your work, there is a piece of you in it. However, it's also necessary. I wrote a whole essay about this here:

https://www.observationalhazard.com/2020/11/on-taking-critic...

The reason I took criticism of my work personally was that I build my identity around the fact that I'm smart and good with computers. If you think of yourself as having value BECAUSE you're good at X - it's almost impossible not to take criticism personally.

You can pretend not to care, because it seems professional - but inside you'll still be hurting, and by default you'll still act to prevent the damage to your ego - anything else will require constant attention. It's not sustainable.

The solution is to detach the perception of your value as a human being from your work.

One option is to be involved in non-work activities. If your only source of self worth is your job, then any criticism to it is a criticism to your self worth. If you have multiple sources of self worth the a criticism to your work has a smaller effect to your self worth.

For example, you might be a dance teacher in the afternoons where your students really admire you or you are the “popular” person among a group of friends.

Sometimes it's hard, but most of the times I find it easy. I think it's because I always assume I could write better code.

That is, after finishing something, if I did a rewrite say a month later then it would have a better design, with better code and hopefully fewer mistakes.

Thus if someone else points out my design or code isn't the best or I've made a mistake they're kinda just pointing out the obvious.

An important note though: this does not mean I don't defend my solutions. They may criticize it, but I judge their criticism before answering. Often I'll agree, after all, most of the time my solutions can be improved. But sometimes I'll disagree and then I'll say that and give my reasoning why.

Some good advice in the comments so far, but I don't see any which highlight the one thing that transformed me in this regard permanently. I suffered from your problem terribly, to the point that it almost drove me into depression.

The one thing that solved this for me, and I mean utterly cured it, was _talking to my coworkers about it_. This of course only works if you feel comfortable being vulnerable to your coworkers. I was lucky enough to work with people who I am also friends with. I literally said to them over a first pint after work: "when I get critical PR comments it makes me feel bad and defensive. Sorry if I sometimes come across guarded that way".

This opened an amazingly productive conversation that changed my relationship with my colleagues forever, as they opened up about their struggles in this area (you would be surprised at how common this is, it is human nature after all) and we shared advice and jokes.

Sometimes I think we (as a software community and species) try to tackle these things alone to avoid displaying our vulnerable sides, but I think this is a tragic facet of modern culture.

Walk away from it, then come back to it in a bit and take the feedback at face value again.

This is obviously easiest with Slack, Google Docs comments, pull request feedback, Hacker News comments, etc. In person feedback might require a poker face and later reflection.

I find, most of the time, that feedback feels a lot less reasonable (and more personal) the first time I see it, but that it feels more reasonable and actionable when I come back to it with a bit of distance. And then there's something to accepting part of their feedback, holding back on some less significant part, for a sort of win/win where you don't have to feel like you gave in on everything.

Easy to say, much harder to do though!

It depends on how many ships you have sailed. Have you worked at different companies and interacted with a good range of people.

If you don't have a lot of experience, you will learn it with time. Check out 48 Laws of Power. Your work also is not everything you have. It doesn't define you.

Criticisms are also not easy to hear because people don't know to give it well. Many times it could be personal. You can differentiate it by how its being framed, is it a comment on you or your work.

Hey Joe, your have become really lazy with your PRs vs Hey Joe, you have repeatedly submitted change requests that don't have good test coverage and have not been able to meet deadlines and it has been slowing down team velocity.

Maybe also consider a change of workplace if you want to start fresh. Going to gym and staying healthy helps too.

At some point, I realized that there's a disconnect between "me" and "my work".

My work is a result of circumstance, like, what my mood was when I did it, how well I know the particular domain, if I've seen solutions to similar problems before, what tools were available and understandable to me at the time.

In other words, the quality of my work depends much more on what the particular task was, than on some inherent quality within myself.

So, try not to let it influence me either way, to not feel some unjustified pride that I made something "difficult", or shame that I couldn't manage to do something "easy".

One liberating tactic I employ, is that I clearly announce when I've messed up, and I'll be the first to do it, and usually with a joke.. "Yeah, so that amazing queue we got up and running last week, I took the liberty to totally mess that up, I learned a lot about how not to do it, I'll eventually learn how to do it right, no worries, I'm working on it." This takes the pressure off, people know it's broken, who broke it, and who's fixing it, and they expect that I come for help if I need it. One thing I don't do, is say sorry, I'm not sorry, this is my job, we do software development, we break stuff, we make errors, and I'm not sorry about it.

The best way is actually to turn the tables around and learn how to give other people feedback in a way that is effective. There are plenty of coaching and other courses you can do that can teach you some good techniques that you can apply.

A useful side effect of knowing how this stuff works is recognizing when others are being ineffective and clumsy. Lots of engineers are a bit deficient with their soft skills. And recognizing when people are shooting themselves in their feet by being passive aggressive, rude, or otherwise causing a lot of issues in day to day communications can help you distance yourself from those situations.

This is what happens when you are identified with your work to some degree. The work becomes you, hence criticism appears to be no longer about your work but your person.

My experience is that this often happens to individuals who have a perfectionist tendency. A very admirable trait that unfortunately can backfire in the form you described.

I think you already made the first step, which is becoming conscious of this. In my experience, the second and harder step is to stay conscious.

For me personally, it helps to take a step back and get some distance from work (even if it is very short).

Also, what greatly helps is not condemning yourself for your reaction to that criticism as that would just add one more layer of negative feelings on top of it.

The reason you react this way shows some very positive traits in you. Appreciate them.

The author is dead, the work is the work, and process creates the work.

If there's problems with the work, you can look for improvements to the process that made it.

If you're criticizing yourself or beating yourself up, you won't find what things could be done differently because you're too busy saying woe is me

It is personal.

I've had 18 months working on a project where code reviews were going badly wrong so my perspective might be a little different than it was before this and maybe needs some realigning, but your PRs probably aren't anonymous and reviewers absolutely do change their comments depending on who the submitter is.

If they're genuinely constructive comments made in good faith by a warm and open reviewer prepared to take the time to help you address them, I don't tend to find people take them badly. If that's what's really happening then maybe some retrospection is in order. Your code isn't you, it can be changed and improved and once committed it isn't yours alone if it even was before then.

Reviews inherently revolve around social dynamics, personal relationships every bit as much as a dispassionate, logical view of code. As such, they're fraught with difficulties.

To speak to the point about the PR comments, it's quite tricky to get a sense of the intention behind them. In the last few years I have adopted the approach of conventional comments, which has helped a lot with conveying that intention.

I.e. if I want clarity around a code choice it's clear to the developer that I need more context, or if I have a nitpick to point out it's clear that that's why I am pointing it out. I think everyone should comment in this style as it helps to shed light on what you're trying to express, even if the comment is short or unintentionally snarky.

https://conventionalcomments.org/

Of course this doesn't address all the forms of text communication but PRs are generally a pain point when it comes to interpreting meaning.

I took project management lessons, it made me realized that a lot of things that goes wrong is systemic (knowledge transfer not done correctly, review processes not implemented correctly, timelines not well managed that leads almost mechanically to more bugs,... etc).

What you have encountered is actually one of the necessary steps to really become "a senior developer". And congratulations, you have already passed the biggest part of that hurdle: becoming aware of the issue.

There are things that are fragile, things that break when it encounters a shock. Such as porcelain, when transported. There are things that are non-fragile, things that do not break when they encounter a similar hit. Like teddy bear, when transported. And there are things that are anti-fragile, things that improve when they get shocks. Like the immune system. If you are not exposed to series of smaller shocks as a child, your immune system does not develop properly.

So you need to develop an anti-fragile attitude towards criticism, in order that you can become better developer from the criticism. If you do not learn that, you will be stuck at the level you are at the moment. You can do this at the meta-level as well at the same time: become anti-fragile towards handling criticism in general, and becoming a better human being from it.

The key to hacking yourself is to increase your awareness of your emotional state. When you become aware that you are angry, the anger is losing the grip it has over you. When you are angry, you are sometimes doing things you would not have done if you were not angry. (Sometimes anger is healthy, it may also be a signal to us that our boundaries have been violated.)

I treat criticism as a valuable resource to help me grow, and I'm grateful that somebody took the trouble to help me do that.

I remember someone once asked how their business could be more successful. The reply was to fail more often!

We will often learn best from our mistakes, if we let a bit of our ego go and avoid being defensive.

Having said that, I'm not some saint! I have to remind myself that criticism is valuable to me, it's natural to feel a bit defensive.

In art school, we spent a lot of time learning how to give and receive critiques, because the fastest way to improve was to try frequently and critique often.

You learn very early to divorce your ego and sense of self from your artworks and embrace every attempt as an opportunity to improve towards an ideal you can never reach.

You also learn how to give meaningful criticism without being an asshole.

Writing code is very much the same.

Unfortunately, most software engineers haven't been to art school and have no formal training in how to give and receive useful feedback.

I recommend reading Art & Fear: Observations On the Perils (and Rewards) of Artmaking. It's a good book that helps you build a healthy mindset towards growing as a creative:

https://www.amazon.com/Art-Fear-Observations-Rewards-Artmaki...

Assuming the criticism is valid and not nit-picking, embrace the fact that this is free education that isn't saddling you with additional six-figure debt!

Learning on the job is important, and you could treat it as such. (Pay attention to the sort of mistakes you are making, classify them, address the reasons that you are making them. For example, maybe muscle memory leaves you forgetting to check some assumption. Maybe you can invest in linting/testing/patterns that make those classes of errors less likely?)

If you're making small mistakes that are noticed, one way to fix it is to make those mistakes less often -- even better if you can stop your team making the same class of errors too.

If the criticism is more about the way you are doing your work, maybe the focus should be on "soft-skills" instead. Are you expressing your ideas clearly in some well thought-out manner BEFORE coding (so that you can get input and buy-in from other affected parties?). Is the churn in the codebase causing others to be negatively affected in their daily work having to react to the changes you are making? The default opinion of most folk is usually "change is bad", so you need to build a reputation of making net-positive contributions. Solicited feedback from people you work with is very valuable for gleaming where you might be missing this mark.

Given how you express yourself, I wonder if you could have some success finding one or more ways to afford yourself to be more detached from your output.

I can sympathize with where you are, as I believe I've been there, but am not there any longer. I've detached somewhat successfully from my own output by virtue of two things, the first and most important one is adapting a growth mindset, which you can read more about here

https://thelearnerlab.com/

and I carry that mindset shift in all parts of my life. Outside of coding, I do a lot of physical activities, and I have meaningfully changed the way I conceive of "failure" so that I have an easier time feeling inspired to try again.

Honestly, I sometimes try to learn by trying to fail as fast as possible. It's quite enriching and takes less of a mental toll.

Besides reading the articles on the Learner Lab (there are some good Power Company climbing podcasts where they interview Trevor Ragan - the guy behind it - that I much prefer to the articles) there is another active choice you could do and that'd be reading the first few chapters of The Rock Warrior's Way which talks a lot about how _not_ to derive a sense of personal worth based on how your performance is perceived by external parties.

Lastly, and this cannot be done actively, eventually, you might find that after you've written buckets and buckets of code during your career you simply care less about it as every design choice you make becomes a smaller percentage of choices you've made in the domain. I believe that's something that has happened to me

At the beginning of my career when I was out to prove myself, I took my job so seriously that my sense of personal self-worth was intricately tied up with the quality of my work. After a particularly disappointing experience that knocked me off my horse for a while, I concluded that putting some distance between my career and the subjective experience of my place in the world was essential to my mental health.

I try to be mindful that the relationship between my work and my person / identity is one of many such relationships in life, and maybe even not the most important one. I think that mindset makes it easier to accept criticism or even to reject it when I think it is irrelevant, misguided, or malicious, as unfortunately workplace criticism can sometimes be.

If your work is being fairly criticized, it's an opportunity to learn and grow. Take it as a compliment that someone actually cared enough about your professional development to offer advice on how to be better. It means they already think that you're good and worthy of improvement. On the other hand, be willing to accept the possibility that that criticism is not actually constructive but intended specifically to make you feel guilty or ashamed. Unfortunately, some people are just petty, small-minded, and manipulative, and will do anything to make you feel small in order for them to feel big.

Years back I worked with a senior guy whose motto was “feedback as a gift“. At that time in that company, most people pretended that feedback was important and something they wanted to engage with, but he was the only person I knew who genuinely lived the concept: he would request feedback briefly from everyone in virtually every interaction, irrespective of the relative levels of seniority.

Anyway, this effectively flicked a switch in my brain. Pretty much overnight I went from finding feedback personal and awkward and even offensive, to feedback being something positive and helpful. I think that actively wanting and requesting feedback, rather than grudgingly receiving it, puts you on the front foot psychologically, and after a while, it becomes second nature.

So that’s my advice: decide that you want feedback, then live it. Go out of your way to actively solicit feedback, and make a habit of regularly giving feedback in a constructive fashion.

Don't think of it as criticism. Instead it's a free mentoring\class\lesson received in the context of your specific domain. Use it. Embrace it. Take from it what you agree with and drop what you don't.

I find that it’s important to be objective with respect to these things. Some people are very good at this, have great ideas and you should listen to them. Most are not, do not and you probably shouldn’t.

In other words, criticism from someone you rightly respect is to be seen as a gift.. a learning opportunity. The rest (vast majority) can be ignored.

https://youtu.be/pWdd6_ZxX8c ;-)

> Do not attribute to malice that which is adequately explained by incompetence.

It's rare that people are trained in the art of criticism. Most of us try our best, but often fail at criticising the work while separating it from the author. It's hard to criticise while simultaneously empathising with the target.

I often think of this when I've received criticism that stings. Most of the time it's simply carelessly written. Ironically, empathising with the critic reminds me that they're only trying to help.

I still remember working hard on some work before showing it to the boss. He pointed out a number of ways in which it could be improved. I wasn't thrilled with his reaction, but followed his instructions. I was surprised to find that the project was greatly improved, and that the criticism was worth taking on board despite my initial feelings.

I was like this but reality beats it out of you over time as you are experiencing right now.

The reality is you will make mistakes, even if you are the best programmer in the world.

You can shift your mindset and accept that you are making mistakes which you are blind to see and then get feedback as early and often as possible to deliver a better outcome.

Now I welcome any type of feedback, regardless of the tone because you can think about it and fix it if it needs fixing.

Anything worth building requires multiple iterations to get right.

Adopting this attitude will also help you in the workplace because people love to work with people that take nothing personal.

Code ownership is a code smell. Your nose is being put out of joint because you interpret criticism of the code as criticism of you. But it's not, it's the team's code, and the team is making suggestions to improve it.

* * *

You are not your code.

That's a saying that helped me, and stuck with me, when I was figuring this out. I see someone else commented the same. I'm gonna leave mine too.

Stoicism has a lot of information about how to react to the world and your emotions. A lot of people think it’s just have a stony outward appearance and burying your emotions, but it’s actually much deeper than that. Recognizing that you ultimately choose how you react to a piece of criticism is the first step. Understanding that the flairs of emotions that you have and your thoughts are not you is another. Once you understand that it becomes easier to practice (and you have to practice) stoicism in your everyday life, including during criticism

I’ve found it helpful to remember that the thing being criticized was created by a past version of me.

A version that didn’t have all the information, a version that doesn’t have the skills and experience present me has, a version not even present in the conversation.

It’s a small way to create some distance between the work and your person.

Another thing to remember is to always ensure the criticism is against the work and against some shared measure of quality.

Too often criticism actually is personal (unintentionally or not) or the criticism is about a requirement that wasn’t shared at the time. Both of which are about the inexperience of the critic not you.

"criticism" is a bit broad, there's a few different scenarios:

- If someone reports that my code crashes with some seemingly valid input, I won't take that as criticism, but rather somebody trying to help improve my code. It's for their own benefit, but still it's still a contribution.

- If someone points out some stupid flaw in my code and has a suggestion on how to improve that, I'll also welcome it as a contribution. It's also an opportunity to learn from the mistake.

- If somebody points out that some code is imperfect (but works in the intended use cases) with no suggestion or obvious path on how to improve it, then they're just being annoying. I have other stuff to do, so try not to pay attention to this (I'll admit this is harder than it sounds).

- If somebody points out that my code kinda sucks and points at something else that's better written, I'll appreciate them sharing some knowledge and go look at the other code and see what I can learn from it.

Generally, I when somebody points out a problem with my code, I'll assume they're having the same stance that I do when I report issues. When I report issues, I generally want to help them get fixed to improve the program since I want it to work for my specific scenario (and for anyone else trying to do the same).

Being someone who always complains about things that are broken (or can be improved) help understand that when other complain they're just trying to indicate that things can improve. They're (most likely) no trying to attack me.

1. Own up your mistakes. Write emails that say: "yup that's on me, sorry guys". This is going to turn your world around. Do it enough time, and you'll see your coworkers doing it too.

2. Try self-derision. "Oh man, I must have had too much to drink that night!!!!" or "yeah I got pretty lazy there...". Always very appreciated. Especially if the comment from the co-worker is intentionally snarky.

3. Try and be pre-emptive about it. If someone says: "hey wtf is going on in prod?", you should answer: "shit, it's probably me, I'm looking into it", or if you think it's not you, you can do something like: "I fiddled with this code yesterday, but I am fairly confident that it's unrelated, let me know if I screwed up".

4. Own up your colleagues' mistakes too: "Sorry guys we screwed up on that one". Clients love people who tell them they're sorry rather than people who come up with shitty excuses.

5. If it's far in the past, insult your past self at will. "Well when I wrote this, I was pretty lame I didn't know better".

6. Always remember that what's in the past can't be changed. Only the present and the future matter.

7. Be kind to other co-workers who own up their mistakes.

8. Thank people who fix your bugs.

There are a lot of hidden benefits hidden in distanciating yourself emotionally from the code you wrote:

- You won't want to continue working on "your baby" when your boss offers you a promotion

- It makes the team work a lot more human. We aren't geniuses, and even geniuses screw up. It's all fine.

- If you own up your small mistakes, no one is going to throw you under the bus if you make a much bigger mistake.

Good luck.

When you’re 20, you care about what everyone thinks about you. When you’re 40, you don’t care about what other people think of you. When you’re 60, you realise that no one was really thinking about you anyway.

You probably won't see my comment as it's late to the party, but these things help me:

- You are not your work. Try not to take any demerit toward your work is pointed at the work, not at you as an individual.

- Make an effort to do the best job you can given your resources, knowledge, and deadlines. Sometimes you have to make trade offs because of an aggressive deadline and it's not the best situation to put out the highest quality code possible. Make sure it's known and try to get back to fixing it the best way when there is time.

- In code reviews, use it as an opportunity to learn from your seniors and to try to come up with ways it won't hurt you or others in the futures. If you made a mistake that affected a model or some code in another area, ask how they knew that would affect it? Is it documented anywhere? Are there tests? Is there a better way to handle this so that it won't affect things negatively downstream? This will help you and others avoid that mistake next time

- Assume that the person making the comment isn't doing anything intentionally to be snarky or shitty, but call them out on it if it's a repeated offense. It's very easy to come off meaner/short/curt through text than speech and some people just don't realize it. Alternatively, they do realize it and they're being an asshole to not just your but others. Either way, this will challenge them to think and act more professionally

This is my framework:

1. Acknowledge to myself that I don't know everything. Do the work to the best of my abilities.

2. Anticipate criticism with the optimism that I will learn something from it

3. Receive the criticism, and take time to really understand it. If I don't understand, I ask questions until I do understand. If I do not believe it is better than my solution, I make my point the best I can.

Part 3 is the tricky part because communication is hard. But all team members have to discuss in good faith and understand that the team is more than the sum of its parts; each opinion should hold equal weight (even if its between a junior engineer, and a team lead).

Two points: is your goal to be perfect (i.e., make no mistakes), or is your goal to improve the product? In the later case, constructive criticism is only moving you closer to that end goal, and can be welcomed happily.

Second point, do you respect the person giving your work criticism, and do you accept that it is useful for the product? If yes, then great, why feel bad if the goal was to improve the product, and their criticism will only make your work better. If no, then this can be a difficult situation, and I personally have been here before. I try to see things from their perspective, ask questions, etc., but there are definitely times when you will fundamentally disagree with the utility of the criticism, and this can indeed be a hard spot.

This all said, the manner of delivery makes a big difference. "Do better" is not useful feedback because it is not actionable. If you are getting this kind of feedback, consider finding a new job / manager. Feedback that is well thought out and actionable (e.g. "this can be refactored like so", or "this function needs another test case") is more than likely coming from a perspective that has seen many things go wrong, has an intuition about what can go wrong, and can be a learning experience for you. Sometimes, the problem cannot be articulated so clearly, in which case your manager should be careful to say so and they will have to put in some thought themselves into the problem and how to find a solution. If they are not then they are only doing half of their job.

Here is my approach:

It is okay to take criticism personally on the path to not taking it personally. Your thoughts and emotions are not you so first and foremost don't feel bad for feeling this way. I'm not saying you should act on them however.

I suggest sitting down and making time, remembering the feeling and then feeling it. No need to psychoanalyze, and have mental talk. Just feel the pure emotions and be curious about them. Where do you fee them? what shape do they have? how big they are? what texture do they have? etc

The point is to make the task of feeling your emotions interesting for your mind so it stays there enough to get used to it.

Hypothesis: When an emotion is causing us suffering it is usually because we don't want it, but unfortunately thats not how they go away, especially if they are big emotions.

After a while your mind will know the emotion so intimately that it will either be negligible or not come up at all.

Note however, if you go towards the emotion with the intention of it going away this will not work, there must be total acceptance. So cultivating that loving curiosity may actually be the hard part. The trick there is that I like to imagine myself as a child having these emotions and soothing this child as a caring adult.

There are other methods but this has been very helpful to me and I hope it will be helpful to you as well.

Imagine for a moment that every time you submitted your work the only feedback you ever heard was "Great" or "Thanks". How would that make you feel? Engaged or isolated? Would you wonder if they are even giving your work proper consideration? Feedback is critical to improvement. Improvement is a continuous never ending process. Try leaning into it, Actively asking "Where is this falling short?" "Where is my thinking flawed?" Soliciting comment in this manner makes you an active participant in the feedback process.

Having followed this approach for my entire career, I can say that it has paid off handsomely. Some of the most valuable criticism coming from professionals that would not have offered actionable feedback had I not pushed past their initial stock "looks good" response.

Most of the time criticism = engagement, a person taking time to pay attention to your output. Making yourself vulnerable in this way will encourage a subset of others to behave similarly, which could lead to some pretty awesome peer relationships. Certainly has for me.

Park your ego at the door when you get to work.

Base your ego on the success of your relationships (mom, dad, siblings, wife, kids, gf, friends whatever you have today).

It will take investment, self awareness and ability to forgive and forget.

You could direct this investment to work relationships BUT more than likely none of those folks will be at your funeral.

I found the suggestions here pretty useful: https://news.ycombinator.com/item?id=36069151

I had a job where they gave training on how to constructively engage with the open source community, and one of the big points was, "you don't suck, the patch sucks".

Oh you have a bug in the patch? No, there's a bug in the patch. Oh you missed an edge case? No, there's an edge case nobody had documented yet.

The point was mostly about how to give feedback on the patch, and to never phrase it about the person personally, but perhaps it would help to try and catch yourself thinking of the feedback this way and have your internal dialog look at the patch as being separate from you.

Yes, it's your work, but it's always a work in progress, and it's everybody's work to try and make incremental improvements to the code, to the process, etc.

I used to think I didn't like working with inexperienced engineers, but I noticed that what I actually didn't like was people who were unwilling to candidly discuss ways to improve, whether they were junior or senior - it's just a little easier to spot in people more junior than one's self. So kudos to you for recognizing this, because if you can learn to absorb constructive feedback it's a real game changer for you and for everyone around you too.

> I've come to realize that I often take constructive criticisms personally.

Somebody once told me, "never fall in love with your ideas." Because you are not your ideas. You are not the things you create. Your work and your creations exist outside of you and they can receive criticism without it being targeted at you personally.

> Everything from an unintentionally snarky comment in a PR I've made to someone highlight a mistake I’ve made that I probably couldn't have known about.

When someone points at your work and says "this is bad" they are not pointing at you and saying "you are bad" are they? And if they are attacking you directly, and not your work, that seems more like a problem with them than it does you.

> I see this as one of my major flaws and try hard to mask how I feel. But I just hope to learn to stop feeling bad for honest mistakes.

Feeling your feelings is not a flaw. Wanting to stop feeling bad is worthwhile, but many people accomplish it by becoming calloused and cynical. They stop caring about what they do and both they and their work suffer accordingly.

Focus instead on separating your feelings about yourself from your feelings about your work. Be critical of the things you're doing. Acknowledge where things aren't great but you're trying to do better and nothing can be perfect.

Congratulations - you have already succeeded enormously by seeing that this is the case.

Stoicism.

If something that someone says or does causes a problem for you, it is something inside you that is the real cause of the problem.

It takes lots of work but you can eventually work on controlling your thoughts and you can learn to deploy counter thoughts. “I have a problem when people say this, so I can discount this particular negative thought that is occurring right now” etc.

I have found that informing others out loud about such struggles is awesome as well. “Thank you, I have had problems taking such and such feedback before, but I am working on it.” You can actually turn this weakness into your strength as people like people who are honest about working on themselves. They might package this feedback differently, or they might let you know in a sensitive way.

Two things: Humility and Empathy.

Humility I may be wrong, Empathy that if I get it wrong the customer will suffer (in varying magnitudes, of course)

Some of my first programs were in C. 100s of Hours and millions of switch to terminal, gcc, error message beat it into me -- "The computer isnt wrong, I am" . Now I am ok with hearing "This code has properties you didn't anticipate" because that's been true millions of times. And it's produced the humility, that I can't get it right on first try, and it's rare I get it right even by 3rd or 5th try.

Instead we implement, seek feedback (from compliler, tests, peers, more tests, datadog), iterate.

And I like to remind myself also of empathy. Do my feelings matter if it's going to affect the customer? If I get reactive and refuse to solve someones feedback, the customer will suffer. If I get reactive too often, it will silence the feedback (but not improve my coding). The customer suffers, so for that reason My feelings do not get a vote.

Edit: Ok "millions" was hyperbole. A better estimate is something like half a million compilations/builds in my ~20 yrs writing code in a non-hobbyist context.

Criticism is the least of your concern when you live with PTSD :D.

For me work has always been sort of an escape from myself. If I get criticized for the work I do I don't mind too much really because the alternative is the dark place I go to every time I close my eyes.

"So you think there's a problem? Okay maybe there's a problem let's have look at it and reason about it together.

Oh I just suck and my face is stupid and that's why my code sucks? Well I'm really relieved we found the answer to our problem, for a moment there I thought I was the a*hole ;D."

That being the dialogue playing in my head while I haven't said anything to the workmate who simply refuses to listen to reason.

"Okay" I type, and press "Submit Comment"

> But I just hope to learn to stop feeling bad for honest mistakes.

A: By trying to fix them.... this is the way.

It is simple, the difference with people that take feedback personally and the ones that don't, is that the last people are willing to make an attempt to fix the problems the others don't want to be bother.

I always take personal feedback with this mentality "ok fine, lets do it your way", if it works and its either better or equal than my solution then fine good for you, if it isn't then its the awkward/refreshing? moment when you have to tell them they were wrong and you have proof.

The answer is simple: identity. Insecurity comes when we find our identity in our work and our ability to do it—but our value as people does not and could never derive from it.

Think of it this way: do your friends or family care about you based on your ability to perform to a certain standard? Of course not! (At least I hope not... that's its own problem).

Once you no longer identify with your work, you're able to take the emotion out of it, because it no longer affects how you feel about yourself. When you get to that point, you'll be able to see every experience as an opportunity to learn and improve, no matter who or where it comes from, which is the ultimate goal.

As far as dealing with other people, it's a lot easier once you've figured yourself out. You're better able to recognize that everyone's on their own journey, and their ability to deliver feedback in a constructive way is more about them than it is about you. Once you internalize these things, you'll start to care a lot less about their opinion of you.

Also, from my own experience, learning to confidently look stupid (i.e. admit that I have no idea about something), has been one of the biggest and most successful hacks of my career.

In summary: You are not your work. Focus on your own journey, and unsubscribe from giving a crap about what other people think about you. Conversely, it'll earn you more respect.

You know, you could consider getting therapy. Being sensitive to criticisms often results from something deeper, such as insecurity or some kind of vulnerability. There are lots of different therapeutic modalities, but CBT may work well, since you can look into the roots of this mindfully, and develop meaningful changes. It can be more than coping or masking.

I’m going to go out on a limb for the next two suggestions, particularly the second one.

Psychedelics with a strong therapeutic intent, can not only help loosen the psychological armoring we create to shield us from vulnerability, but also help make changes when belief structures can be cleaned up and changes. You would want to work with people who do this way (instead of partying with it), or with therapists that administers this with a clinical protocol. These should include integration sessions to help bring the insights and changes to your daily life.

There is also the option of working with acupressure or acupuncture, with the caveat that most licensed acupuncturists do not know how to work with this. They usually take a holistic approach and stick to what are called the twelve ordinary meridians. If the roots of sensitivity to criticisms is in your physical health, this may catch it. Holistic treatment though, means the provider won’t specifically target what you came in asking help for.

If you are lucky and find a provider that works with the eight extraordinary meridians, there are two specifically related to sensitivity to criticisms. These are the yin and yang qiao mai, with the yin qiao mai directly expressing your consciousness’s ability to receive criticism, as well as insecurity, vulnerability, etc. Yang qiao mai expresses your ability to give others criticism without being a jerk.

It’s not as if using these methods are like using a magic pill. However, they can greatly accelerate whatever therapy you are working with.

I am on opposite spectrum where I don't fully understand why people take constructive criticism negatively. Over years, I have learned to offer criticism only if asked and only with a lot of praise. (Though I still sometimes make mistakes of being direct with people I am close with).

My parents are highly critical, perhaps, that's why I am not bothered by constructive criticism. Though useless and unasked criticism still bothers me.

I went through something similar. The core of it for me had to do with a fixed mindset vs growth mindset.

The research behind this showed that telling kids something as simple as "you are good at this" vs "you worked hard at this" can trigger a fixed mindset. This shifts their focus (and potentially their beliefs) that it's about them personally as opposed to the work they are putting in. From there all sorts of crazy things happened. Kids would protect their status moving forward, going so far as to lie to others about how well they did on exams. Meanwhile the kids that thought it was about the work they put in continued to grow, improve, and get better - leaving the other group behind.

With this knowledge, I began to change from thinking about comments and feedback to be about me and instead about things I've produced. Eventually it lead to me being able to respond with curiosity, embrace (and celebrate) mistakes, and to learn things much much faster.

This may sound odd, but I now have a visual I play in my mind to help navigate this. In the past, the visual was when getting feedback the other person was pointing at me when saying things - which felt like blaming, shaming, etc. Now it's that they are pointing at a piece of paper in front of us that we are both looking at. That piece of paper has things that I've produced and we are discussing it. It shifts the focus and blame from me over to discussing the results of my actions. This gives me a mechanism to mull over how to change my actions in the future to get different results.

In the context of things that aren't outright mistakes..

It's important to take some feedback as .. others desires for features, and attempts to share experience with you.

It is easy to use software we write for ourselves, it is important to understand that no one will find our software as usable as we do. Taking feedback is how we get to write software that is usable by more people.

And as you grow in your career, you will meet people who had negative experiences in different ways than you. When this is shared via feedback, it is best to learn from other peoples mistakes than to repeat them.

1. I stopped seeing my work as a labor of love a long time ago. I love what I do, but my passion is with the technology, not the day-to-day commits. My work is generally good and I'm confident that I'll continue to be valued, but my job output isn't some kind of masterwork (nor does anyone want it to be).

2. The whole point of code review is to find issues. If my code was perfect, we'd skip review. But it's not, and I accept that my mortal flaws will inevitably show in what I put up for review.

3. Criticisms are one of the few feedback mechanisms for your real, tangible job output. It's important to remember that you grow technically by others pointing out mistakes. If you got nothing but praise, you're not actively refining your skills. Catching mistakes before you submit for review is indeed a skill that must be honed.

If the feedback you get is snarky or mean spirited, that's a culture issue. Reply politely, thank them for pointing it out, ask if they have suggestions for what to do better if the right answer isn't obvious. Establish a norm of treating code reviews as a place for being decent. If you don't get respect in return, take it up with a manager: code reviews at work are no place for someone to make you feel belittled.

One technique can be listening to the self-discovery of others. This is germane to your concern: https://www.tiktok.com/t/ZTREgGosr/

This individual explains how their process of sharing feelings on something is often perceived as an accusation by others.

from my experience, acquiring the self-awareness you need in order to articulate this problem is the biggest hurdle to solving it -- you're on your way!

early in my career, i shared this hangup and because i was so emotionally invested in the products that i worked on, i considered criticism of my work == criticism of me personally.

i think the next step is evaluating how effectively you are separating your work and personal life. when i have struggled with this issue the most, it has correlated with me being too emotionally invested in what i'm working on.

make sure that you have projects and interests outside of work that fulfill you so that you don't rely an outsize amount on your work for fulfillment. often this means having better guardrails about work-life-balance -- do you clearly define when you are and aren't available for work, for example?

the other thing is simply reminding yourself that your work isn't you, and it doesn't define your value. working with complex systems, we are going to screw up at times, it's an inevitability. if you aim to not make mistakes, ever, and bristle when they are pointed out or criticized, you're going to struggle over the longterm to get along with the people you collaborate with.

ironically, i have found that being more open and accepting of the "dumb" shit i do leads others to think more highly of me as an engineer. i think most of us can think of "that person" we've worked with who can't take criticism and recoils when questioned -- when you do, how did that you feel when you experienced that behavior firsthand? if i had to guess, it probably wasn't positive. we can do better!

It's natural to take criticism of your work personally so I think the first thing is to accept the initial emotional reaction as "ok" and not something to beat yourself up about.

The next step is to tame your emotional response. It's almost never a good idea to act based on emotions so you first need to get a level head before responding. You can journal, meditate, go in a room and rage out if you need to, but just get that chimpanzee in your brain to settle down. Not easy but has to be done if you want to transcend whatever is coming your way. Sometimes you will fail but there's always next time so just keep at it.

Once you've settled down, now it's time to rationally consider the content of the critique and decide how to respond. Criticism can come in many different shapes and sizes: valid, invalid, clear, vague, harsh and nice, well timed, ill timed. Unfortunately, some people can be downright mean so handling harsh and uncivil criticism is a skill that takes time to master. If you notice most highly successful people, they take nasty criticism like water off a duck's back. That being said, it's really unacceptable to have people making snarky comments on your work and if it's a pattern there, I'd consider finding a more nurturing place to work.

Once all that's done, decide whether the argument is valid and if so make the adjustment in good faith. If not respond, with your reasons respectfully and with an open mind. They may respond in turn, and if so you and your colleagues will have achieved a harmonious spirt of working together towards a higher truth and you will benefit in ways that cannot be overstated.

There is a legitimate difference between accurate, honest advice that is hard to swallow, and being harsh, rude or mean. For some reason that I don't fully understand, some corners of the programming world seem to conflate the latter with the former (sometimes under the guise of "brutal honesty").

Sometimes you won't have a choice and you just have to put up with it. But my advice, in so far as possible, is to surround yourself with people who understand this nuance and for whom it is a goal to be compassionate (while still being honest and truthful about problems that exist).

I just wanted to mention it because some of the advice in this thread doesn't seem to make this explicit. Improving yourself is great, but life is too short to put up with jerks.

I do not take criticism of my work personally. I think this is because I have already heavily criticized it myself. Everything I make falls short of the ideal form I have pictured in my head. This applies to code, woodworking projects, CAD models, documents I've written and food I've prepared. These works all feel separate from myself despite coming from my brain. That is not to say I'm not proud of them or feel like I've done a good job; quite the opposite! But at the same time it is very rare for me to feel like there is not room for improvement or even obvious shortfalls.

I think with this mindset it is easy to accept others criticism because I already agree anything I made is needs criticism and is worthy of being criticized. It is also one of the only ways to improve. I get excited when I can get someone to provide feedback on food I've prepared (people are hesitant to do that as it seems rude) because it teaches me what they like. For software, sometimes the criticism is just someone else's preferred style and that I take even less personally and try to work with them to see if there is a middle ground that suits both of us or our team.

At my first job, I was on a small team and my boss did all the code reviews.

He would leave comments like:

- "This is really awkward, change it to..."

- "This variable name is awkward and confusing"

- "You have failed to understand..."

- "You are overthinking this. Keep it simple and do..."

- "This causes unnecessary overhead. Think about it..."

Every review, I would have to re-write everything to exactly how he wanted it, variable names, logic and all. To the point that the code was not mine.

I would very much disagree with what he wanted. Any type of constructive push back would be met with enormous backlash.

But it wasn't always what he wanted me to change, - the way he delivered the feedback irritated me the most.

In my following jobs, I have had many reviewers for my code. I've had 30+ other people review my code. They have all been much nicer. And deliver feedback that I actually agree with.

I am thankful when someone finds a bug in my code, or an easier way to do something. Using a function that I am not aware of. This way QA won't find the bug, and I am learning.

Anyways, my advice is to look at how the person is delivering the feedback. Take note of that, and know it is them if they are toxic. And when you do a code review for someone else, be sure not to be that person.

It took me a long tome to mostly get over this, but a turning point was realizing how temporal code is. It’s written in a snapshot in time, to solve a problem that may evolve hour by hour, competing with dozens of other tasks also needing attention.

So what you produced in that maelstrom is really just a reflection of the moment, not of you.

A frame of mind that helps me is: I am doing important and difficult work and I cannot expect it to land perfectly. Whether it's because I did something wrong or because I didn't explain it well, the "surface area" for someone to see something I missed is pretty large.

So you go into your day expecting that there'd be feedback (and in fact if you don't get any, you should be concerned) Then when you get it, it's not something that smacks you in the fact, it's something you wanted and expected.

BTW no all feedback is useful, you'll still have to filter it for relevance but you need to have an open aperture first.