Ask HN: How do you not take criticism of your work personally?
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.
Comments
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.
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.
Since I have been working in this manner people are more open to changes themselfs. It works both ways.
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.
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.
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 :)
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
https://www.observationalhazard.com/2020/11/on-taking-critic...
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.
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.
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.
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.
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!
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.
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.
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.
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.
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
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.
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.
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 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.
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...
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.
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
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
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.
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.
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.
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.
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.
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.
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.
- 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.
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.
- 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
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).
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.
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.
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.
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.
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.
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.
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.
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.
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"
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.
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.
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.
My parents are highly critical, perhaps, that's why I am not bothered by constructive criticism. Though useless and unasked criticism still bothers me.
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.
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.
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.
This individual explains how their process of sharing feelings on something is often perceived as an accusation by others.
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!
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.
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 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.
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.
So what you produced in that maelstrom is really just a reflection of the moment, not of you.
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.