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.
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.
There are things that are fragile, things that break when they encounter a shock. Such as porcelain, when transported. There are things that are non-fragile, things that do not break when they encounter a similar shock. Like a teddy bear, when transported. And there are things that are anti-fragile, things that improve when they are exposed to a shock, 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 to become a 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.)
Exactly. And if that boundaries get violated repeatedly in the same situation (especially by the same people), it is fine to release that anger in a controlled way. I've come to the conclusion that some folks haven't left the state where they sometimes need a (vocal) pat on their hand to realize they crossed boundaries they shouldn't cross. If you can play that game, congrats.
Also, do not swallow your anger. Find a non-destructive, non-harmful way to release it. As anger is a physical reaction, the easiest way is to go for a walk, ride your bike or whatever. Whatever floats your boat should be fine.
I’ll also add that journaling is an absolute game changer in terms of actually debugging/thinking through problems.
Meditation = “give this a minute or day to simmer”
Journaling = “now that I’ve cooled down, what are my actual thoughts on this matter”
I’ve been astounded on dozens of occasions to learn what my own thoughts really are, for the first time, by seeing them on paper. I.e. it subjectively feels like I don’t think the thought then write it, but instead I write it, read it, then think it.
One of the core techniques is to visualize the emotion as another person as you try to talk to it and discover more about what it is you're feeling, eventually coming to a strong connection with the feeling. It's been an epiphany trying to process emotions this way for me.
[1] https://www.amazon.com/Focusing-Clinical-Practice-Essence-Ch...
I myself started meditating on my own, when I was 11/12 so that is definitely an age, when you can do it serious.
My own kids (< 5) are too small yet, that I would do serious meditating with them, but some sort of pre exercises, like just sitting still in nature and observing, do work since the beginning.
Don't push them obviously. Rather give them a chance, to explore mindfulness and consciousness with you. I can also recommend Tai Chi/Qui Gong as an more active path towards it.
I have found meditation to help me to stay calm in situations, and even if I am about to get angry, to become aware of it in situations, so I can remove myself from situation before acting. And also to calm down more quickly. When you can process the criticism from a better place in yourself.
Also, I have found tai chi to be have similar effect on me.
AIUI, CBT's primary method is to convince you to pause between feeling and acting, so that you can ask yourself if you have made an accurate assessment of reality and can plan an appropriate response.
If you are angry, it is difficult to discern what are the truths. So it is useful to approach criticism both from good and bad intentions both in the same way. In other words, by default, if you get angry, try to figure out what in the criticism makes you angry.
In the professional world, giving feedback with tact and respect for the contributor is what we get paid for and enables a team to contribute to the company’s success.
If someone on the team doesn’t feel like they’re treated with respect, even when their work needs improvement, it doesn’t matter whether the feedback was given with good or bad intentions.
If there is a person consistently giving hurtful feedback and I would be in a position to get the person fired, I would do it. (And I have done it.) And I would not work in such a work environment. At least 50% of programming work in typical organizarions is about getting along with people.
But I have found myself in environments where I needed to tolerate this to a degree. And the only thing you can ultimately change is your own attitude. If you can see that hurtful criticism may be even more truthful than other criticism, it helps to develop the right attitude.
Of course, the dangerous part is that you may learn the wrong thing. Extracting constructive feedback from criticism that was not intended to be constructive requires a certain level of self-confidence and psychological safety that's only possible when it's an unusual event rather than a continuous drag on your self-worth.
(Easier to say than to embrace, of course.)
"Anti-fragile attitude" when it comes to criticism is not built by tolerance. Quite the opposite actually. It is a common misconception. While making yourself numb against criticism IS a solution but not by far the best one.
A high criticism tolerance is learned by understanding that ones self worth is not attached to output or delivery. (This is hard in our industry) It comes from self-acceptance and compassion. And these values are learned early on. You'll find that the people that break down at the slightest criticism the most are those that were criticised the most as children as well. Those that had no room for being anything other than perfect. Where value was obtained from performance.
To take it even further...why see it as criticism at all? You are not your lines of code.
Another adjacent PoV is improvement, not complete, is the steady state.
What I mean is, throughout our entire schooling career we did work and turned in assignments that got graded. They were done. The work was over.
Our professions aren’t like that. There’s no done. There’s always improvement.
Therefore every piece of criticism, critique, or feedback has some data in it (sometimes layered in poorly worded phrases that can feel mean) on how to get better.
Your goal is to figure out what that data is and whether it’s valid, then act on it.
Extreme Ownership teaches a mind shift of looking at criticism and thinking of it as 'GOOD'. Criticism is an opportunity to improve.
Like anything, it's about balance. Sometimes, it really isn't anything you should be doing to fix (or anything you should change).
exist to exist the whole way through. do what you gotta do.
many SV people have probably also seen anecdotal evidence the $B crowd has this mindset. it's the $M crowd sweatin the small stuff.
Yeah, perfect and ready to be exploited with no end in sight.
What are $B and $M crowds? Billionares and millionares? Do you have any personal insight into those or just read about it?
To use an analogy if you're poor disputing a $2 charge is meaningful because it might double your disposable money. But if you're rich you could absorb 1000x $2 charges per day without even seeing a difference in your first 4 digits of your wealth. (eg 4522188456 squints to the same number as 4522180456)
I think you're closest when you say "A high criticism tolerance is learned by understanding that ones self worth is not attached to output or delivery"
The compassion part is unnecessary.
Any criticism you take personally is ultimately a fictitious story you're choosing to accept about your identity. We are the ones choosing to take an event like a comment, apply a label of snarky, and allow it to set our emotions in the moment.
The snarky comment itself has no objective meaning. It only takes on meaning when we decide to interpret it negatively. We could just as easily screen the comment for actual valuable feedback, and if there is, implement it. And now you have a win. How smart of you, you should feel good about that.
The real approach is rising above and seeing things for what they really are, and seizing opportunities to look at things differently for an optimal outcome.
Agreed. And nobody's lines of code are perfect.
It took me a long time to realize this applied to me. I don't ever remember explicitly being criticised as a child but I reached adulthood with a wicked need for perfection and "achievement" and a subconscious aversion to criticism. I still find it hard to feel valid and valuable in the world other than through work. But all of these behaviors have undoubtedly held me back in work and relationships.
> You are not your lines of code.
These statements are sage advice. And while I believe them both to be correct, I personally struggle with remembering these things when it matters most.
{"You are not your lines of code", "You should feel proud when your code is good and embarrassed when your code is bad"}
Both of these things are true.
To the matter at hand, how to take criticism constructively, the key for me is bifurcating my emotional response from my logical one.
Emotional response is noted, thought about, but routed inward. Logical one is routed outward.
E.g. "This is the dumbest application of a bad sorting algorithm I've ever seen."
Emotional/inward: "That hurts. Am I a bad programmer? How did I not know this? Will I ever be a person who does know things like this? I respect the person who's telling me this: do they still respect me?"
Logical/outward: "Fair. What algorithm would you have used in this application? If you have time, can you walk me through how you would have picked it?"
People usually screw things up when they don't hold space for their own emotional response and commingle it with the logical one (e.g. manufacturing a logical justification for what is really an emotional feeling).
A great phrase for what I've been noticing about my life as well.
{"You should be okay with who you are", "You should always strive to be better"}, or {"Desire is the root of suffering", "Being passionate about a goal is the only way to fulfillment"}
Finding the nuances in these phrases and living in the bubbles where they are not actually contradictory has given me a lot of peace.
Now, what we should realize about the code isn't the thing of value. It's what the code does and how it does it, that is the runtime output and the ability to express the intent to produce that output to a programmer who hasn't seen the output or the code before or in a long time.
Criticism is the best opportunity to improve those aspects of the code you write. So it should be of equal value to you as the lines of code the criticism is addressing.
Not all criticism is valid, even well-intentioned constructive criticism. Experience teaches you which critiques to accept and which to reject.
The only way to gain that experience is to solicit criticism from others, and give it to others.
No, we are not just our code, but our artifacts are a part of us, as we are a part of them. So we should be kind when giving criticism and gracious when receiving it. Because what we choose to do with our time matters.
Furthermore, the idea of separating one’s self-worth from “what one does” does not make sense to me either. If someone’s worth is not tied to what they do, then the criminals, liars, frauds, cheaters, etc., of the world are every bit as valuable as our loved ones, idols, great contributors, etc. That view doesn’t make any sense to me; I wouldn’t be disappointed one ounce if all the criminals on the Earth vanished tomorrow, but I would be greatly disappointed if all my friends disappeared. The only difference between those people is “what they do/have done”.
If you take the view that our achievements are necessarily integral to our self worth this logically isn't true.
Saying "well it's not all about what we do!" is not in keeping with the conversation.
You can’t logically derive this from anything. It’s just a choice of how to see the world. “Worth” is inherently a subjective value judgement.
Most of what we do and how we think is not “logically derived” and is extremely subjective; we’re human, not Vulcan.
What you are doing is a higher goal than a PR, and detaching yourself from the minor details allows you to achieve this with greater flexibility and skill in the long term.
You have to take steps back and see subsequent bigger pictures and see what you’re doing within the context of a product, a job, a pattern of self-improvement, a fulfilling life.
That way any criticism that helps you improve your game, no matter how unpleasantly delivered, is a power up.
I say it glibly, like it's easy, but it works if one can internalize it.
It's important to recognize the ebb and flow and to be kind to yourself.
Take criminal behavior as an example. Someone reliant mainly on extrinsic motivation are also the same people who will not know what the right thing is when no one is looking — or worse, they are bad actors when no one is looking. Being intrinsically motivated for moral behavior requires you to really examine what is right or wrong.
This includes self-worth. I don’t think most people who are mostly extrinsically motivated realize the extent of social engineering and conditioning used so that society benefits the wealthy few .
If failing at a project means your a failure then you’re too close.
Failure and mistakes are how you learn.
If failure and criticism are about you then you will always be defensive about and flaws, perceived or real.
So yes be proud or disappointed, but have the distance and self confidence to believe it is expected and normal to make mistakes/fail at things on the path.
As the other commenter said care about the trends and 1st derivative not the individual data points.
For me there's a big difference between being disappointed in what I've done and feeling bad for what I've done.
If I write some shitty code, which I still do after 30 years of programming, and my colleague points it out, I feel disappointed. But I don't feel bad. I fix it, try to learn from it and move on.
One is an implied notion of objective rankings of worth of humans, and binary labels for people. Your post explicitly categorized “all criminals” and “all my friends” at disjoint sets. I can’t speak for your friends, but many of mine are “criminals” in the sense of disregard for drug laws. If you’re willing to sweep minor traffic violations under the heading “criminal” you’d probably sweep up most individuals with drivers licenses. Is the hypothetical person stealing so they (or their children) can eat irredeemable to you? There are certainly folks who on net do more harm than good, but rare are the people who truly only do bad to the world.
Second is a matter of perspective. If your friend started a new thing today, say learning the piano if they’ve never played an instrument, would you expect them to be good? If not, would you think less of them for trying? What if they’ve been playing for years, and one time when playing a song they’ve practiced many times they miss a few keys? Now replace the friend with yourself. Does your feelings about any of these change?
It’s not uncommon (especially in programmer types) to allow others more grace than we allow ourselves. You can be disappointed by your failures, and thrilled by your successes without impacting your sense of self worth.
Looking at your piano examples, if I had a friend who took up piano, I would admire that, because I value learning. I wouldn’t expect them to be good, and I would not think any less of them, because it is the gumption to try something new and to learn a new skill that I find value in, not playing the piano. If they had been playing piano for years and made mistakes, I would not think any less of them, because I don’t value the ability to play the piano. Presumably, after many years of practice, playing the piano would hold a lot of value to them (or it held value to them so they practiced; the point still stands) and so it would make a lot of sense to me that they would feel worse when they made mistakes; those mistakes demonstrate to them that they have less of something that they value.
Like I said, we all have different value systems, but our self-worths should be tied to how well we live our values, i.e., our integrity. If our self-worth is not tied to how well we represent our values, then it is, IMO, baseless.
Do they throw good parties?
Do they help their friends celebrate their successes and provide succor in times of need? If so, why shouldn't they feel some self-worth?
The person you posited has more self-worth, by definition, than the self-doubting programmers in this thread. Precisely because they are getting by while doing something much less "meaningful" or "useful" (as evaluated by others) than a job in software engineering.
(Of course, I'm talking about the hypothetical person I imagined when I read your post; most such people that I've met in real life actually feel pretty bad about themselves, party to numb the pain, or because they have nothing better to do, and actually feel worse after they've had their "fun", et cetera. But let's roll with your scenario for a second, I think you're on to something important.)
Maybe this person doesn't have to suck up to a pointy-haired boss, or doesn't have to mentally model arcane concepts that are subject to planned obsolescence anyway, or doesn't participate in the violation of people's minds facilitated by the infotech industry.
Or maybe they still do the aforementioned things but on their own terms. Maybe they code for fun and write malware when hungover out of pure malice. Or they don't. Maybe they're a hooker on smack and just shat on your floor. It does not matter. What does matter is that this hypothetical person does not have the experiences that make you ascribe "negative" or "insufficient" self-worth to yourself.
In other words:
* You can be an absolutely awful horrible piece of shit person by anyone else's (or everyone else's) standards and still have a feeling of self-worth. This is by definition: self-worth is the worth that you ascribe to yourself. No matter how much you care (or not - it's a choice) about other people, self-worth is self-worth; worth to "civilized society", "a value system" or "an individual other" is not self-worth, by definition.
* On the other hand, the "need" to experience something that others call "self-worth" does not in fact originate from the self, but is a vague obligation imposed onto you by others: the obligation to have some sort of nebulous experience that others call "a feeling of self-worth".
* There is no such thing as "should feel worthless": nobody gets to tell anyone else how to feel. Imposing an obligation on someone to experience an emotional state is, technically, a violation of bodily integrity. Yeah I said it. Whatever real, physical neurochemical process lies behind the experience related to the concept of "self-worth", is a normal part of the body's homeostasis, serving to ensure the self-preservation of an animal that is able to kill itself for entirely abstract reasons (such as awareness of own mortality, and downhill from there).
In even fewer words: in my book, someone who is an "ok friend" and throws "average parties", is defined as "a waste of my time". But they still get to live on the same planet and breathe the same air as me with my silly book. I don't get to decide their self-worth for them, and nobody, and nothing, gets to decide that for you, either.
Therefore: you can feel perfectly good about your successes and failures without even entertaining the notion of there being a concept of "self-worth". According to nobody in particular, this is actually preferable, for Occam's razor reasons if nothing else.
In theory, you can be a very "successful" person and still feel worthless; in practice, the feeling of worthlessness usually prevents one from becoming "successful", and makes it look as if it's the other way around.
Ultimately, the matter can be put like this: do you see yourself as goods to be bought and sold? If yes, then go ahead and demonstrate your high "feeling of self-worth" as much as you have to. If no, then why even bother with pricing yourself?
Absolutely true and exactly my point: while you're feeling what others want you to feel, you're missing out on feeling things that do translate to actual, valid insights about your reality.
For example, this whole absurd notion of "self-worth" that we're discussing here. It's there to scam you into thinking about yourself what others think about you - even though they're not in your shoes, and may even have a vested interest in seeing you down.
Even the name of that concept is misleading (how is your self-worth dependent on your worth to others, unless you yourself make it so?). And here we are talking about "reality" as if human social reality is not predominantly a linguistic construct, and constantly subjected to these absolutely ridiculous abstract symbolic switcheroos, that people only fall for because they believe they have better things to do than get their thinking in order.
>You can feel whatever you want to feel.
But you can only want what you feel like wanting. So you're still trapped: desire is either intrinsic or mimetic, feelings are conditioned, yada yada.
And I'm pretty sure you can't actually "feel whatever you want to feel" - not without a Nozickian "experience machine" or years of advanced meditation practice, anyway.
Well, this seems like an extreme attitude that doesn't account for a large swath of how the world actually works, and is often gotten to that point by personal bias and not questioning beliefs constructively.
Its flawed because its an overgeneralization.
To provide an example, are there people that have been wrongfully convicted. Have any of those people been put to death as a result of those convictions. Assume for a second that you are one of those persons, and 12 people based upon some judge or skewed evidence chose that. Are you valueless? Who chose that you would be convicted? Wrong place at the wrong time?
There's a movie with Russel Crowe called The Next Three Days. It covers this type of premise. We never have absolute information, we have interpretations which are just as malleable as a game of telephone.
As for your ideas on value systems and integrity and self-worth, there are contradictions and its a bit convoluted. It fails to make distinctions between things within and outside your control, and the ever present ability of others to deceive sometimes even without their knowledge.
Whether society accurately captures and properly deals with those people is an entirely different subject. The fact society even has to do so is a net negative
Depending on how harshly one judges oneself is the reason for not handling criticism to ones failings. No one is perfect so one better be kind and try to learn from their mistakes and not take it on their ego.
So I think what people mean when they suggest detaching their self worth from their code is that they shouldn't take criticism of their code as a personal attack but as a chance to learn and grow. Hence "you are not your code": the attack isn't a direct assault on you, it's a technical argument about the actual code itself.
Words and emotions are easy to fake, deeds are much harder.
Being a person gives you value which cannot be take away.
It’s a philosophy, so one may reject it, but a lot of people separate their personness from their work because of the idea that each person is valuable in their own right.
If you derive self worth from results, then you could be disappointed by circumstances outside of your control.
Suppose you set a goal to make $1 million by age 30. At age 27 you're doing great and (through no fault of your own) you are struck by lightning. Because we're playing pretend let's just say your insurance doesn't cover lightning strikes and so medical bills drain a lot of your savings and you cannot continue your career and you do not become a millionare by 30.
If your goal is just the million, then you are a failure. You did not make it. If instead you derive self worth from your values, then you can still be a hard worker (or maybe your value is being self-starting, or entrepreneurial, or something else), even if you are struck by lightning.
> If someone ought not feel a negative emotion in response to doing something “bad”, by what logic can they justify feeling something positive in response to doing something “good”?
I think this section is pretty close to what I'm advocating here. "Good" and "bad" are doing a lot of legwork. What is good and what is bad? I'd wager if you asked people of different religions or ideologies or backgrounds you'd get a whole swath of answers here.
> I cannot conceive of a world view that allows one to feel proud of their accomplishments but does not require their disappointment in their shortcomings.
You might find that you attribute too much to yourself here. It can feel good when you are succeeding and sometimes the system at large is a major contributor to your accomplishments and your shortcomings. As an extreme example, I don't think that someone accomplishing little and suffering under Apartheid is worth less than someone benefiting from that system that accomplishes a lot.
> If someone’s worth is not tied to what they do, then the criminals, liars, frauds, cheaters, etc., of the world are every bit as valuable as our loved ones, idols, great contributors, etc.
To me it would depend why they commit crimes, why they lie, cheat, etc. Someone is stealing bread to feed their family that is very different from someone stealing taxes for a public project. Going back to the Apartheid example, an interracial couple would be breaking the law, and although they are criminals I would not want them to disappear for that. They could have even done horrible things to protest Apartheid and I would still not want them to disappear. If they had rotten values then sure.
To detach emotions from work without throwing out the value of good work: attach your self-worth to something UPSTREAM "doing good work", a cause of good work, and not the work itself. You do this by realizing that the emotional attachment to your own work was never really about the work, it was what the work implied about you; the emotional brain jumps to conclusions. Good work, when you zoom in as if with a better telescope, that you are responsible, capable, well-intentioned, generous, intelligent. These can be ends in themselves—you'll disappoint yourself when you fail to live up to them, for their own sake. Those are better ends—they let you say "I DID address everything I could think of but I missed something, I'd better learn from that", rather than feeling something you missed as a vague attack against your whole being. And because, you often try to prove we are all those things—fearing you're not—but fool ourselves with things that don't really prove it—like material wealth, or attention, or good grades. And then even if you succeed you are left with some guilt: "I got the good grades but I feel like I could have done something more important..."
You can take it further: those attributes, when you zoom in further, resolve further, into a feeling that you are worthy of existing, and worthy of love. In my experience (I have felt this, but I haven't learned to live like it), feeling "worthy of love" gives you permission TO love, to be good—which again you can invert. It's the right reason to be responsible, capable, etc—all of those flow outward from something deeper rather than being ends in themselves.
Sometimes people are having a bad day. Sometimes someone has a different view of 'good' than you. Sometimes someone just got served divorce papers that morning out of the blue. And none of that you can control, or even do much to influence many times.
However, being aware that having others value the output you produce gives you things that benefit you - like help pay the rent - in combination with other factors, and is therefore important to you. But it's different.
Looking at your work and being able to judge yourself if you did a good job, is healthier, and more productive. If you're seeing that others judge the value of it differently, it's worth investigating why.
There may be something you're missing (different values, or they don't like your face, or they hate the language it's in or the style, or they haven't been laid in years, whatever).
If it is something you can adjust, it may be worth doing so. If not (or not worth it), it may be worth finding somewhere else with different values. It may also be worth adjusting your judgement of your work based on those factors, IF you think they're valid and it will improve things in your favor. Sometimes, it's worth just writing off the feedback or defending yourself, because it's coming from a toxic place from them.
But if you do this, they won't be personal attacks, because it isn't about you (as in who you actually are), because they can't know the truth there anyway. People don't work that way.
It will be about their perception of the value of what you produce to them, or their perception of you. Which is not up to you (directly), but you can influence it, and often has little to do with who you actually are and more to do with specific things you can concretely do a bit differently and change.
Does that help?
Absolutely, but:
1) not all of that value, just the value as someone who does that work. I mean, it would be crazy to think that you have no value as a dad to your three-year-old because you made some crap code design.
2) not for all possible values of "someone else". Just those someone else who have a clue about the work, and make specific, objective criticisms that are verifiably true, and who understand the context of the work: what are its requirements and non-requirements, including constraints.
3) I don't necessarily want someone else to think everything I make is of high quality; however, the right somebodies should more or less agree with me about the quality. If I make something and think it is of medium quality (for some justifiable economic reasons), then if someone thinks it is of great quality, I will regard him as a fool; but if someone thinks it is of garbage quality, I will wonder whether I might not be a fool. Ideally, we should be of one mind with everyone who understands the problem and the work. If the work is mediocre, everyone (including the author) should find it so based on some objective criteria. Everyone who understands the economic reasons for why it was made mediocre should ideally agree with that also. "Ah, I see; I would have done it the same with regard to that purpose and those requirements."
It’s easy to say ‘no, my value as a person is not due to if someone likes my work’, but emotionally we can still be in that place for many hard to address reasons.
And under stress (which we almost all are), balancing out all this to come up with ‘good enough’ and managing all the stakeholders understanding of ‘good enough’ to come to a successful outcome can be really hard and even more stressful.
So I guess what I’m saying is, if rationally someone understands, but they are still reacting that way, there is almost certainly a real reason, it just isn’t one they are able to see right now.
So maybe some yoga/excercise, or some meditation, or going outside for awhile and touching grass can help too.
Us engineer types tend to ignore emotional and physical health sometimes, especially when there is something scary or exciting going on. And we have a ton of that right now.
That is a great point... but the answer is that you should also take your accomplishments with a grain of salt.
Basically, yes, your outcomes are a function of your inputs (talent, work, etc.), but it is a very noisy function and people usually underestimate that part. Sometimes you do the right thing and fail anyway, in the sense that "the right thing" is a strategy that succeeds with probability 95%, but today just happened to be that remaining 5%. And if the next day you apply the same strategy to another task and succeed, it doesn't mean that you have improved.
If you want to base your self worth on your outcomes, at least choose the long-term trends over the short-term noise. If you usually do a good work, then the bug you made yesterday should be interpreted as an accident, rather than you being bad at what you do. And vice versa, the successfully completed project is a combination of your skills plus the good luck of not having one of those accidents today; both of them were necessary together.
> If someone’s worth is not tied to what they do, then the criminals, liars, frauds, cheaters, etc., of the world are every bit as valuable as our loved ones, idols, great contributors, etc.
Let's not judge moral character the same way we judge talent. To be a great contributor is a combination of character and talent. To be a criminal is a failure of character, but there are both talented and talentless criminals.
A great novelist would be foolish to let some editor's remarks about spelling errors and run-on commas destroy their self-worth as a writer.
If a knowledgeable critic points out problems like the plot being a series of unoriginal tropes, and the characters being paper-thin stereotypes, that has to strike at the author's self-worth as a writer. I don't see how you can get around that.
First one's free: your accomplishments contribute towards your own well-being; your shortcomings are towards everyone else's disappointment. If you feel that your failures have disappointed others, you don't actually need to disappoint one more person (yourself) before you are allowed to do better. In practice, experiencing that emotional state is usually counterproductive (unless your goal is to make the others feel sorry for you). Just become aware of the failure and start looking for actionable root causes; no beating yourself up necessary.
You know, you did not even choose to be here in the first place: this world brought you forth into itself, by way of your ancestry, and imprinted its ways into the clean slate of your nervous system, by way of your formative experiences. "Perception of self" is just one of those imprints; "selfhood" is simply learned behavior.
(Even though it's next to impossible not to learn some form of selfhood, is it surprising in the slightest to say that different people's demonstrated perceptions of self can vary considerably?)
While "success" and "failure" are eminently useful notions for categorizing perceptions of feedback from the outside world, the only thing that makes these notions have any bearing at all on your perception of self is... force of habit. You have the option, and the moral right, to unlearn that habit. Nobody even asked you whether you want to be a "self"! You did not even exist when that choice was made! So, why feel responsible for whether you end up perceiving yourself as a "good enough" self? Don't you already have enough things to be responsible about, that are not entirely in your head through no fault of your own?
Expecting people to have internally consistent worldviews, or even an objective and logical perception of their own selves, is very, very idealistic. In my experience, people who are disappointed in themselves actually learned that from their parents and peers (and, increasingly, media) during the early years of their lives; it's this attitude of self-deprecation which sets them up to fail and guides them into a vicious cycle. While people who somehow avoided being taught this mentality in the first place, tend to be more resilient, not afraid to try, fail, then learn from failure and try again.
(Most people who don't kill themselves kinda-sorta end up unlearning self-deprecation and learning how to bounce back even from tremendous self-violations; but you have limited neuroplasticity, limited access to experiences, and limited time on this planet, so the sooner you start, the better. Don't wait until you can only learn internal resilience at the Pyrrhic cost of becoming an incorrigible narcissist, they're making too many of those already!)
>Furthermore, the idea of separating one’s self-worth from “what one does” does not make sense to me either. If someone’s worth is not tied to what they do, then the criminals, liars, frauds, cheaters, etc., of the world are every bit as valuable as our loved ones, idols, great contributors, etc.
You are confusing "their self-worth" with "their worth to you". Now, how could you? I think this is a really horrible, egregious, evil mistake for someone to casually make in the span of a couple sentences; I honestly can't fucking even. YET... you are still valuable to me, since you are the reason I am writing this message, you might even be receptive to my worldview, and I definitely do give a damn whether you get my point! No more, no less.
(Of course, for some reason people feel their self-worth diminished when someone points out what's basically a "syntax error" in their thinking. I think they teach 'em that in school through Pavlovian conditioning or something.)
You know, even horrible people are valuable to someone! Besides, it takes a great deal of self-worth to be a successful criminal, or even a petty liar! Especially because things can get overwhelmingly complicated really quickly, and advanced opponents can smell you doubting yourself. Narcissistic character is another case where one's self-worth and one's worth to others are grossly mismatched, to comic and often tragic effect.
What I would advise you to do (and yes, I am crazy, but I am not fucking with you), is to try listening attentively to some gangsta rap and try to put yourself in the shoes of... no, not an impoverished, radicalized African American youth; but of a well-to-do entertainer who successfully confuses the audience into believing that they are an impoverished, radicalized African American youth. And has the sheer audacity to accept more money for their controversial burlesque act, than you'll ever see for all your real hard work, that has actual, objective value for others, that everyone agrees on!
It's truly the eye-opening experience.
This is a very consequentialist framing of values. There are other ways of conceptualizing values, like virtue ethics and deontology, so if you're actually interested in understanding a different modality, those are keywords you can Google.
> You'll find that the people that break down at the slightest criticism the most are those that were criticised the most as children as well. Those that had no room for being anything other than perfect. Where value was obtained from performance.
My childhood fits this.
> "Anti-fragile attitude" when it comes to criticism is not built by tolerance
I DID learn these by tolerance!
> self-acceptance and compassion. And these values are learned early on.
I learned these LATE on, in college. I feel like it's typical for a kid, but I was insecure and very much afraid of failure. But when I encountered sustained failure despite my best efforts, it pushed my "attached to performance" ego to the breaking point. That ego broken, I was forced to decoupled my sense of self worth from my performance. I didn't do it consciously, either; it sort of just happened one day. And I literally mean on a day. I felt it the day it happened. It felt like a weight had been lifted, and I found myself unable to care as much, just all of a sudden. I wondered if it was depression, but I felt happier than I ever felt before.
That nerfed my performance somewhat, since it's no longer driven by a frantic self-flagellatory imperative to prove my self-worth, but it also made my quality of life much higher, which I consider an easy trade.
I still care about what I do, and I very much still try to do a good job. I'm just not terrorized when I don't. I feel bad when I don't, but not "I'M A PIECE OF SHIT" bad. It's a more impersonal bad. It also allows me to sincerely welcome criticism; there's no sting to it at all unless I did something colossally stupid and/or the criticism is, like, downright verbally abusive or something (which it's never been so far :p).
I agree with your overall statement, but I think the specific point above could be misinterpreted in a nonconstructive way. What it seems like you're trying to say is that we shouldn't just be learning how to deal with criticism by tuning it out or building up defense mechanisms against it. That I agree with. However, another interpretation that could be implied from your statement is that one should not be seeking out criticism, which is not good.
What I think OP is getting at is that learning to process criticism comes by experiencing criticism over and over again. Some of the worst responses I've seen to criticism have come from those who constantly make concerted efforts to avoid it. Understanding that you are not the sum of your output is important, but it's really hard to remember that when you're right in the thick of it. Being able to control your emotions and thoughts within that moment come from having experiencing those moments over and over again.
The point of criticism is to learn and improve, but in order for that to happen one has to be able to actually hear and process the criticism being offered. One needs to get past the emotional response to criticism in order for that to happen. The two big pieces of that are decoupling the value of what we're being criticized on from our inherent self worth, AND being able to control our emotions in the moment. The latter is really only done by having enough exposure to it, and that's the "anti-fragility" component.
The opening was that comment A was saying something about how they did <programming subject> and comment B was asking probing questions. I recognized that B was leading A towards a certain framing she had in mind(a very Uncle Bob, OO patterns are the answer kind of answer), so I injected a flat "there's nowhere else that code needs to be except one of these two places, classes have nothing to do with it."
B responded with "but surely they have to be in a manager class right?" And seeing the resistance to taking any other framing, I got more assertive and instructive in my reply, giving specific recommendations to try dispensing with OO and experiment with writing more primitive code. This was the offense, and it became an argument, which was basically a stomping because I was very prepared with sources and a rationale for why I am making that recommendation, and B fell into defenses from experience and authority, talking about numbers of lines of code and systems she had made and accusing me of speculating about her ability.
And then I said, "that's nice, but I'm the comments section." Apologized for the offense, and pointed out that she started replying to A by speculating, and had admitted as much. Finished with encouraging words for B continue writing the code that she felt works best.
She wasn't happy with this, and said I "hijacked" the thread and used a "condescending tone", but also allowed that I said interesting things.
And it's like, was it worth getting into another "arguing with strangers on the Internet" cycle? Part of why I engaged in the way I did was because I was coming off a period of answering other people's questions, so it was, at first, just one more of those.
But afterwards I realized that what I had disturbed was the belief system. The original thread was an attempt to confirm B's belief to herself: that's why it was done in a leading manner. A lot of comment threads proceed along those lines. When I just wander in and negate that, defensiveness is immediate. Saying "it can only be these two things" is only condescension if you're certain that your other way is already right. B wanted to brush it off. What I was doing was starting the "put on the glasses" fight scene in They Live.
And I think part of why I've gotten better at navigating those threads and critique generally, even if I might be overbearing or "condescending" at times, is because I can recognize when a principled defense is taking place. Good technical discussions start from a place of philosophical credibility. They don't start from norms("this way is best") and then question-beg their way into justifications. They lay out the assumptions of what's true and what's being achieved, like "eliminating a form of error"(one of the goals I outlined in that thread, and the one which ultimately made B concede) and then find conclusions inductively, deductively or abductively. Once you get away from the philosophical goal and only aim for winning the argument, you start crafting harmful rhetoric.
So the answer for me lies in philosophical training: you do have to intentionally "turn it on" to think in those terms, but it lets you be more effective around criticism, to "dance" with it and see it as a process, not a prelude to violence.
And it is much harder to deal with open comments than any one specific critic, because those are subject to mob mentality. Offend a belief the mob holds in high regard, and regardless of the principles involved, you'll just get dehumanized right away. I try not to find myself involved with that stuff anymore, but it's like, yeah, of course I have beliefs.
I think you actually are, in a very real sense. Someone else would have written different lines of codes. The lines of code are a function of yourself, an inherent part of you. Criticizing the lines of code criticizes that part of you. You can’t criticize a novel without implicitly criticizing its author. When we criticize an LLM’s output, we are typically criticizing the LLM. Perceiving criticism of one’s own work as something personal is only natural, and logical.
Now, if the criticism is of a honest mistake, you can learn from that, and own the mistake – show responsibility for it by acknowledging it and correcting it. Of course, that presupposes that you agree that it was a mistake.
Often things aren’t that clear-cut. There can be genuine differences of opinion and of judgement. Of course, one is biased towards one’s own work. It helps to be aware of that bias. It also helps to think in terms of picking your battles.
If you don’t quite agree with a criticism, it can also help to give yourself a chance to change your mind a bit. Maybe later you’ll actually mostly agree with it. And that later changed you isn’t the former you that was criticized. Win-win!
I disagree on the strongest terms. You need to work with a mindset to your own growth an evolution. It was me who wrote these lines of code an hour ago, but I would not have known to write them a year ago and I will know better than to write them like this in another year's time. Possibly I wouldn't even write them like that now, having thought about them for an hour.
I am not a perfect coder, some Omnipotent god. Everything I write is a tradeoff of my current set of knowledge and the pressures I'm under and is therefore inherently flawed.
If someone criticise my code it's because they either know more than me, in which case I have learned why I shouldn't have done that and will adapt for the future, or it's because they know less than me and I haven't clearly explained the tradeoffs in which case I have learned that I need to express myself more clearly and will adapt that for the future.
(Of course it might just be because they didn't bother to read my commit message but that's a different problem)
If you believe that your coding ability is an inherent part of you, then they are not different. If you believe that your coding ability is an ever-changing attribute of you but not core to who you are, then they are very different.
If x is 5, then x + 5 and 10 are the same thing. If x is 3, then x + 5 and 10 are not the same thing.
A good question to ask is which model is more useful, or which model is more likely to lead to various outcomes you might want. "Me=my code" is pretty good for producing top coders and winning competitive situations. It also tends to produce burnout and assholes. You aren't stuck with always using one or the other, either. A lot of people start with "me=my code" when younger, then switch partially or fully to "my code=my code" later when their initial model starts leading to conflict and inefficiencies in a system larger than just one or a few developers. (Or they start finding value in non-coding pursuits.)
That was definitely not my intent, and I'll take that on board as an area to improve on :)
I disagree that the code I write is "part of me." It expresses a series of ideas that I had. And every therapeutic modality I have tried would have failed if I didn't have the implicit understanding that I have something like a soul or an essence that stands apart from my thoughts and feelings. My thoughts are just random noise in the grand scheme of things, including this sentence.
I can't stand the way that some people write, but that doesn't amount to a criticism of them as a person, unless I choose to make it about that.
I don't understand not feeling bummed out by that type of critique. Sure it's not about you as a person or your values, but dang that sucks.
When I read "I can't stand the way some people write", I get a similar sort of feeling. The intention is not that it is a harsh statement, but to me it's very harsh (although not on the same level as the example I wrote).
To me, this highlights the problem with criticism and why the thread is a bit divisive. It's a gap between intention and perception with different end results based on how feedback is perceived.
That's what your code is. It's a picture of your thoughts at a particular time, constrained by the process of translation onto the medium on which it is being viewed. Some part of you is in there, but the thing itself is not you and it doesn't make sense to view it as a completely accurate representation of yourself. You got caught thinking with your mouth open, oops. Just try again.
The attitude of desiring to learn is what keeps me sane, but I've learned that feedback like "X is bad" often comes from someone's subjective experiences in a particular situation. They then take that and apply it globally. It's hard to have conversation with such strong opinions.
Having a trusted coworker who has a disagreement, followed by a healthy conversation will result in either the change they want, the original staying, or a new solution that's better. Growth can come from all 3, depending on the mindset going in.
I think it is parents job to introduce small disappointments for children. This way they learn to handle larger disappointments. I think we need to teach ourselves to handle criticism in the same way, in small doses.
About not seeing it as criticism, I am not completely sure what you suggest. But I have analogy with improvisation theatre. There people celebrate mistakes, because fear of mistakes is what blocks you from improvising.
So instead of changing the name (to something else from "mistake") to overcome the fear, the fear is met head-first by celebrating mistakes. Similarly, I think the name "criticism" is not important, and if you can overcome the negative connotation for the word for you personally, there is no reason to change the word.
However, that numbness is different than being unaccustomed to taking useful critique without getting defensive. Which is absolutely a learned skill– one of the most important you learn early in art school. Someone unaccustomed to any critique, or only used to complimentary feedback will bristle at any criticism.
Someone used to constructive critique will still bristle at insults, intentional or not, so the EQ of the critic in delivering the message is also critical. The biggest enemy here are people who think that their criticism can be as rude, pedantic, or imperious as they want if the core point is valid. That might provide comparable results for the issue at hand, a) but human beings don't deserve to be treated like that, and b) it kills morale, which kills productivity, quality, retention, etc. It blows my mind how many fully-grown adults can't see that they're only quieting their own insecurities with unnecessary harshness, and that they're essentially stealing self-esteem from the team by indulging that urge.
Having people on your team with poor enough mental hygiene that they need to position themselves above someone else to feel good is a serious problem. I think it's one of the things people really mean when they talk about overly macho bro types or neckbeards.
Typically the sensitivity level of feedback in my experience has encroached into things like "Don't give 10 comments on a PR, its too many and people feel bad" (regardless of the number of faults in the code).
Seven principles for making marriage work[1] - has great advice for many sorts of committed romantic relationships.
Also if he's criticizing you as you described he may want to consider talk therapy/CBT to come to an understanding of the nature of his frustrations and his inability to productively communicate them to you.
[1:] https://www.goodreads.com/book/show/849380.The_Seven_Princip...
For my project, I was building some tools that were helping me understand the problem space (which was new to me and that he fundamentally did not understand himself). In a team stand-up, which included the CTO, I shared that I had built a useful tool that was helping me and he chimes in: "I think that you just spend all of your time making tools and don't do any real work." Even if there was a conversation to be had about how I was spending my time, it was ridiculous that he was bringing this up for the first time not 1:1 but with the whole group. I resigned a few days after that interaction (which was probably at least the fourth or fifth time he'd pulled something similar in the two months I worked with them). BTW, he would never just say "you are a moron" but it was very clearly the subtext of almost all of the feedback he gave, except to the most junior people who didn't threaten him in any way.
ok firstly Comments about the individual in a CR is way out of line.
There is a massive difference between "This code will fail in <a certain way>" and "You failed <, again, like you always do>" ... The latter is out of line and should be addressed head on with a manager present or a person who will enforce it's toxicity.
Now that said, criticism of code should always been allowed. It either has certain properties or it does not. A discussion of economics (scope/timelines/applicability) are a middle ground. But either the code has a race condition or it doesnt. It's easily read (which is best judged by the reader, not the writer)... It's missing some property that is desirable.
If one takes a criticism of code as a criticism of self, that is ego crossing over to where it doesn't belong. I like to remember The bridge will either hold the load or not regardless of how one feels about it. "This wont hold 1 ton" is better information than "Have you considered what happens if you put 1 ton on this?" .. The former informs you of something that must change, the latter leaves uncertainty and obscurity where infact the answer is already known.
Being direct and being polite aren't mutually exclusive, and direct criticism doesn't have to leave out any information at all. Saying "This approach won't work under peak load because" in a code review conveys the same exact message as "Your code will collapse like a popsicle stick bridge the second we hit peak load because" during a meeting.
These types of people are so difficult to deal with and crop up in every community. The problem is that when you find a person like this in a position of power, particularly if you are new to the community, there is really not a lot you can do about it so you are either forced to a) tolerate their behavior (which will likely require setting some difficult boundaries) or b) leave. I just want to emphasize that leaving is not necessarily a sign of weakness. If the dynamics in the community are sufficiently toxic that this kind of behavior is tolerated -- or even worse, glorified -- there is very little you can do besides maybe giving an honest exit interview. But you need to have the self confidence to not let unreasonable personal attacks bring you down to the same level or make you feel as though you somehow deserve to be treated that way when you make mistakes, which we all do.
1) Who will see it? What will be the consequences? If no one, then look past the delivery and consider just the content.
2) Use it as useful feedback and information that you otherwise might have never gotten. Consider how many people may have thought similar things but were too nice to say anything. Finally someone spoke up and told you what others were thinking. Then you will come to regard the (private) exposing of a flaw with appreciation!
3) Treat it as you would any focus group, it is just one data point. Sometimes the frustrating thing is when the criticism is wrong and is just a product of how things are done locally. If you are un a full-time job, just embrace how things are done. If your solution serves many other clients, you may have to file it among other priorities.
When you start to focus on the work and the outcome, you don’t focus on criticism as a personal attack, even if it was meant as one you extract the actual usefulness from it.
As I mentioned in my other post - I make things that I find enjoyable, and while I am not 'numb' to criticism, I just dont let criticism to affect my personal Mortar in the foundations of who I feel I am.
Self-acceptance and compassion can only develop when you have a place where you feel physically, socially and emotionally safe as a base you can return to when you need to re-center.
Safety gives you permission to take risks (financially, emotionally, physically, socially) by having a place to regroup.
This is something many teams misunderstand or are completely unaware of. Demonstrating understanding and compassion to one's colleague's will increase their abilities to communicate and work collaboratively.
Additionally, physical health issues and pain can take away our feeling of safety, and sitting on our butts all day is REALLY not healthy. But it's hard to notice when it creeps up on us.
This only works if you truly believe that you are accepted by your team at all stages of your development, and if the feedback is delivered with the intention of helping you grow.
You are not your work. You can write incredibly crappy code and still be a fine person. You can write beautiful, elegant code and be a terrible person. Separating your work/code from your self-worth is hugely important.
They are lines of code until you reveal them to the world. Then they are part of the world. When someone else improves them (or tries to improve them) you must rejoice that the ideas you have given the world have attracted enough attention to be criticized and improved!
Only by keeping the code private would the criticism be criticism against you. Once you distribute the code, the only truly negative thing someone can do, from your point of view, is to ignore the code.
That’s my point of view anyway. Elsewhere in the thread someone commented positively on your self awareness and in parting I must echo them.
If someone disagrees with anything in the code, you can point them either to a requirement that would have to change if it were done differently, or else some documented best practice (whether in-house or some famous external one) would be violated.
Have a reason for everything. Why is there a linear search in that function? Because the number of items is at most ten, and not expected to ever exceed around fifteen; moreover, the function is called only a dozen times, on first boot after a firmware upgrade.
Also, be the most stern critic you can be, of your own code, criticize it yourself and fix everything, so you don't leave much for anyone else.
Also people who criticize people make a mistake kind of.
Always criticize the code, not the person.
As much effort and ego you put in it, it will still suck in some way.
You wrote some bad code. You are not a bad code writer.
Now sure it depends on the type of criticism in question. Finding a bug or other practical problems obviously isn't, but talking shit about a way something is arbitrarily set up that the author thought was really neat would absolutely be.
This line of thinking also reminds me of how every time some actor or director or whatever is implicated in some scandal, their work is also tainted forever instead of being taken at face value for what it is. Can we separate the artist from their art? Is it even possible? I doubt it.
Code is made to be efficient in a compagny, it's not "personal" or here to make you have feelings. So if you can't discuss efficiency because you'll hurt people it's just bad. If you do art, you create art with respect to your own sensibility emotions so yeah be weary of criticizing someone's art.
There's always external influence, but if you're involved you obviously added something and in most cases it can be scrutinized on its own merits.
And he loved to get "artistically creative" with "elegant variation" of variable names and naming conventions, permuting and mutating them at every level, and making up cute unique abbreviations by randomly dropping characters to save a few keystrokes of typing, then spicing it up with whimsical nonsense like "aardvark" and "pancake", instead of boringly predictable consistent correctly spelled descriptive big-endian names like I prefer. (He claimed that made it easy to grep the code.)
He would even alternate between CamelCase and lowerCamelCase and snake_case and Snake_That_Ate_A_Camel_Case and UPPER_CASE and runtogetherlowercase in the same fucking variable name, occasionally throwing in the random "sam_" and "_SAM" prefixes and suffixes for good measure!
He also liked hard wiring the path of his home directory into code, of course. He was like a territorially possessive dog pissing on all the trees and fire hydrants he could find, and all the code he wrote sucked.
That made it extremely hard to separate the "arteest" from their "work", and not to criticize the person as well as the code. But at least it was easy to tell at a glance which code needed to be tossed out and rewritten.
Please don't be a Sam! There are some people who do deserved to be criticized as much as their code.
Elegant Variation (which is a terrible idea despite its fancy sounding name):
https://en.wikipedia.org/wiki/Elegant_variation
>Elegant variation is a writer's substitution of "one word for another for the sake of variety". The term was introduced in 1906 by H. W. Fowler and F. G. Fowler in The King's English. In their meaning of the term, they focus particularly on instances when the word being avoided is a noun or its pronoun. Pronouns are themselves variations intended to avoid awkward repetition, and variations are so often necessary, that they should be used only when needed. The Fowlers recommend that "variations should take place only when there is some awkwardness, such as ambiguity or noticeable monotony, in the word avoided".
Big-Endian Naming Molds, Code Smells, Smurfing:
Felienne Hermans: How patterns in variable names can make code easier to read
https://www.youtube.com/watch?v=z7w2lKG8zWM
>Name molds let you structure variable names to maximize the chance of different programmers guessing the same name.
https://news.ycombinator.com/item?id=31472523
DonHopkins on May 22, 2022 | parent | context | favorite | on: Felienne Hermans: How patterns in variable names c...
I like to use "big-endian" naming molds (love that term!) to define sets of names that when you alphabetize them place related variables next to each other. (i.e. in a completion menu or browser.)
For example, left_foo and right_foo are little-endian, since the least significant word comes first, so they'll be a long distance away from each other in an alphabetized list.
But foo_left and foo_right are big-endian, since foo is more significant than left or right. So they will appear one after the other in an alphabetized list.
Common suffix words are _x _y _z or _min _max, or _left _right _top _bottom, of even singletons like _enabled _loaded _error etc.
But when you combine multiple dimensions together in names, you need to think of which dimensions are more significant, based on how the variables are used, so use foo_x_min foo_x_max, if the positions are important, or foo_min_x foo_min_y, if the ranges are more important.
Sometimes it's hard to decide or ambiguous, so just try to be predictable and the same as all the other code. Think of which variables should appear closest to each other in an alphabetical list.
And avoid middle-endian or random-endian (or sentence-grammar-order-endian) like the plague. A variable name should probably not be a grammatically correct sentence.
Another really annoying linguistic naming smell is "smurfing," where all of class Smurf's instance variables have smurf_ prefixes. Or where all the classes, methods, or instance variables have an "xyz_" prefix where "xyz" is the name of the project or library. Arrgh!!!
SnowHill9902 on May 22, 2022 | prev [–]
Agreed. When dealing with real values, it’s favorable to explicit the units: weight_lb, length_cm.
DonHopkins on May 22, 2022 | parent | next [–]
Yes, explicit unit suffixes are good smurfs!
Also: eschew Bill and Ted's Excellent Postfix "_not", which inverts the meaning of the variable name. That's a most totally bogus code smell, dude.
The most common way I've seen this done is by becoming numb and not caring at all or thinking others are worth less than you so you shouldn't listen to them. Not options I'd choose for myself.
Numbing to me implies not caring, while detachment from your views can be born from caring about improving.
If you want to improve, this likely involves shedding some convictions you hold too close.
I used to work in a customer facing support job, so I learned some strategies to keep cool from that.
I will strongly disagree that numbing is useful. I grew up extremely emotionally numb and distant. Looking back it never simplified things.
Going through that process over and over again has been incredibly helpful in my professional life, even though most of the criticism I receive is rarely structured like those juries. The first thing I learned is that it's rarely useful to try and refute or respond to the criticism directly in the moment. If that's your instinct, then chances are you aren't fully thinking through the criticism and responding from a more emotional state, which is not good. The key is to try and actually listen (rather than "shutting down"), remember the key points to process later, and to let the person offering the criticism know that you've acknowledged it.
Second is to realize that nothing is perfect. There is always room for improvement, things that you couldn't foresee, and things you simply didn't have time for. Obviously, the bigger those things are the more concerned you should be, but as your work becomes more and more refined, the criticisms become about smaller and smaller aspects of whatever you've done. The goal is not to get zero criticisms of your work, but to have the criticism that you do receive be about less and less important elements.
Third is that someone will always have something to say. Interpret that in a number of ways. If you're getting a code review, you're soliciting someone's opinion or your development process is dictating it. People will come up with criticism because that's what's being asked of them, and even if it's "perfect", responding with nothing makes it seem like they're not doing what they should. People like to offer criticism because it makes them feel important; they see a "flaw" you didn't, even if they don't really understand the totality of what you did. And while its disappointing to say, some people will criticize you for personal reasons, be it against you directly or because they think they stand to gain something by doing it.
Ultimately, you have to decide what is worth listening to and what is not. If nothing is ever worth listening to, then that's something that's likely more on you than the criticism you're receiving. It's also very tempting to discount criticism from certain sources because of past issues with that source. Process each criticism from them in the same way, regardless of the past, because you never know when they actually might have something worth listening to.
I agree 100% with this. Art majors (depending on the school) go through much the same process, with the added bonus that artists can be even more capricious. E.g., "blue is totally the wrong color for that."
Filing the burrs off of your ego is often a good thing. There is an issue with some people who are just not structurally fit for that sort of thing, where the slightest criticism can make them collapse into a heap of self-loathing and depression. Discretion and discernment are important so that you don't break a fellow human. So the flip side is that being a part of critique juries is also training in how to give criticism, which is an important skill in and of itself.
Programming, especially in the open source world, tends to be a very solitary endeavor. It's quite akin to art in that way. And programmers tend to spend a lot of time up in their heads. And they tend to be rather blunt about their opinions. Getting some time in the reviewer and reviewee seat is useful.
That's a little of what I was getting at with some of the points above. Tons of criticism is just plain subjective. How do you evaluate the validity of someone else's subjective decision? The ultimate answer is that you can't if your response to it is to flip the table and leave the room.
>There is an issue with some people who are just not structurally fit for that sort of thing, where the slightest criticism can make them collapse into a heap of self-loathing and depression.
I agree, but I think that in and of itself is a bit of a different problem. A key aspect of the modern human condition is being able to deal with criticism. If the slightest bit of it will "make you collapse" then that's a strong indication that you need some professional help to learn how to deal and process things.
>Discretion and discernment are important so that you don't break a fellow human. So the flip side is that being a part of critique juries is also training in how to give criticism, which is an important skill in and of itself.
I don't disagree that teaching people how to criticize will help have that criticism be better structured, less aggressive, and more constructive overall, but the reality is that we can't expect everyone to have "the proper training". There absolutely were jurors that I had that were more about tearing you down than trying to help improve. Dealing with those people was a learning process in and of themselves.
>And programmers tend to spend a lot of time up in their heads. And they tend to be rather blunt about their opinions. Getting some time in the reviewer and reviewee seat is useful.
This points to the social nature of giving and receiving criticism. There needs to be emotional awareness from both perspectives. Programmers, as a generalization, tend to be more anti-social than other professions. A key aspect of social interactions is empathy; being able to see things from others' perspectives. When I look back at some of poorest delivered criticisms or responses to criticisms I've experienced in my professional career, they've come from the most anti-social developers.
Bluntness can have two interpretations, being straight to the point and/or not going into details. "This is poorly structured" is blunt, but doesn't attack or make things personal. "This is crap" is just as blunt, but has a far more negative connotation and interpretation to it. Neither is all that great of a criticism if they're not expanded on or explained.
Fully agree. I tell people, if you cannot be humble about your code, you're going to deter yourself and others. It's okay to admit you may have "screwed up" (mistakes happen to everyone, even in production) the big thing to do is learn what was wrong, and if there's any steps you could take moving forward to avoid that mistake, the person commenting on your mistake probably made the same mistake, and worse it made it into production and now its ingrained in them.
Developers become adamant to prevent issues they or fellow team mates have ran into, even seasoned developers run into issues. Hell, even architects, and I've seen CTO's do the dumbest decision making.
It's about doing the best you can, and helping others to do the same. Critique on your code isn't critique about you as a person. Sometimes personal statements can leak in and that's different. I find that for the most part, critiques are only about the code, and it's the author that turns things personal which is where any argument is already lost.
This doesn't mean you have to agree with a given assessment, and they don't have to agree with your approach. As opposed to some other comments on this post, I will say that I think the best way to learn how to deal with it is to just keep working, and when you do feel yourself getting emotional, take a step back and review. You rarely are on the spot to respond at that moment, especially for typical PR processes and feedback. Try to put yourself in the mindset to assume at first you are wrong, and second that you are not interpreting the message as intended. Interpret the best possible view of the person and the message sent.
It's really hard to put yourself in that mindset, and it definitely takes practice, time and experience. The best thing that you can do from the start, is stay quiet, step away for a moment, and re-evaluate before responding if you feel emotional.
Our industry doesn't have many standards, and it's not nearly as objective as some think. And often criticism isn't intended to improve an outcome: it's intended to bring others' in line with the critic's view of how it should be done.
All this to say, I'd just add to your comment that one must also develop the ability to discern when a critic is identifying a true mistake and when they are simply parroting a fad or injecting their subjective beliefs into the review.
Maturity means that you can accept criticism that is intended to help you improve. Making you aware of an issue or directing you towards a better solution can make your code or product a better one.
Simple insults thrown from the 'peanut gallery' should just be ignored. If you have built something using a particular language or framework on a particular platform; you should expect those who don't like those things to throw in their two cents without even trying to understand the problem you are trying to solve.
I've found managing situations like this to be the hallmark of a good architect / high-level engineer. I really admire people who are able to think quickly on their feet and push back against people who push for ignorant or unnecessary changes. And it is something I am not good at.
I've taken to silently fixing peoples' mistakes as to avoid these kinds of discussions. While I'd really like to say, our architecture did not force you to push broken code into master hours before you went on vacation, my (agreeable) personality prevents that.
Whether it is a design pattern, deployment strategy, or choice of language, if your argument has no technical advantage then you are just expressing your taste preference. This is where someone will likely call you out by asking, "are we discussing technology or ice cream flavors?"
I'll steal this and see how it turns out.
Even muscle strengthening seems to require minor injuries to the tissue. Tougher but demaged.
You're thinking scar tissue, which analogously would be a maladaptive response to criticism (inflating ego, projecting fault).
Muscle strengthening doesn't cause permanent damage unless you overdo it.
Compare this to true trauma to the tissue, which results in scarring. Scar tissue may be "tougher" (less pliable) but it's not contributing to additional work. A better analogy might have been that broken bones grow back stronger, though even that requires that they are set right and have an appropriate amount of recovery time, which to continue the analogy, might be therapy needed to not be so brittle in the first place.
> We can think of a tree as a dynamic system in equilibrium with respect to the forces of gravity. Tree growth takes advantage of horizontal symmetry around a vertical axis as a way to distribute gravitational forces so that the downward force due to gravity on one side of the tree is balanced by the downward force of gravity on the other side of the tree. When the wind blows, the new force acting on the dynamic system of a tree responding to gravity temporarily shifts its current state, as mea-sured by the tree’s position in three-space, to a nonequilibrium configur-ation, and when the wind dies down the tree returns to its equilibrium configuration, just as models of linear systems with stable equilibrium points indicate how a dynamic system responds to a transient impulse. Let us imagine the tree as being represented by a vertical, straight line ..
This is counterintuitive but actually there is raw science to back the opposite fact up. I'm not joking.
The more delusional you are as in the less ability you have to take and accept criticism the more likely you are to be successful. There is a positive correlation for this verified by science.
It gels with my anecdotal experience too. At the top end of success those guys are the most delusional and least accepting of criticism, for example Elon musk or Steve jobs, etc. Etc.
But even on the lower end of the spectrum, senior engineers it's there too. For example people who claim they are able to unbiasedly accept criticism are often the people who are worst at it.
The reason for this is not any sort of deliberate emotional reaction or anything like that. But rather because the brain actively deludes you from seeing the complete truth. It pushes people to construct artificial scaffolds of logic to uphold their existing beliefs.
Senior engineers are not immune to it nor are they better. What determines the senior role has a lot of factors and definitely not all the factors are related to the actual formal senior rank. A lot of it is luck, time, politics and other bullshit that gets people that rank.
Everyone builds these ideals about their identity, their rank, and their engineering ability. The reality is that a lot of it is delusional. By deluding yourself it becomes easy to include other people in your delusion as well and that's how a lot of hierarchies work.
Not saying their aren't competent people out there, but don't fall for the false belief that a rank like "senior engineer" conveys a certain level of emotional maturity to accept criticism.
Perhaps you could share this verifiable science?
If the 'delusion' is useful and produces better output, then is it really a delusion?
-
To the OP - "Dont give a F"
I make quirky and weird shit that pleases ME. (physical things, like weird bike products, stuff out of leather, etc...)
Some people find them odd, or "why are you doing that?" -- BECAUSE I ENJOY IT, I dont give AF how you feel about it.
From what I recall, exposure to environmental antigens as a child helps train the immune system to not go off on them later (as allergies).
Exposure to any particular disease is only a positive in your adaptive immune system response to that particular disease (and may cause problems such as antibody-dependent enhancement of related diseases, as seen in Dengue, and some Flu infections). For particular diseases such as chicken pox it's better to get them as a child as they have worse symptoms if first caught as an adult. For other diseases I don't know that it matters much. It's probably best to just never catch them at all. And then for diseases such as measles, you don't want to catch them ever (at least before vaccination); definitely not after you've caught other diseases.
https://msutoday.msu.edu/news/2020/Covid19-immunity-Yasser
> Does our immune system get stronger with every infection we fight off?
> To answer this question, let’s first discuss the two types of the immune system. Our immune system is composed of two arms, the innate and adaptive immune systems. The innate immune system acts fast (in minutes) after it recognizes a pathogen and, in most cases, eradicates the invading pathogens. During this process, the cells of the innate immune system, and their derived immune mediators/proteins, also activate the cells of the adaptive immune system which then develop memory immune responses toward these pathogens. Therefore, upon reinfection, the intensity of the innate immune system remains the same. In contrast, the adaptive immune response is much stronger than the initial exposure to these pathogens.
> So, to answer this question, our immune system doesn’t get stronger with every infection but the response of the adaptive immune system is much faster and stronger upon reinfection.
https://news.harvard.edu/gazette/story/2019/10/how-measles-w...
> Reporting today in Science, the researchers show that the measles virus wipes out 11 percent to 73 percent of the different antibodies that protect against viral and bacterial strains a person was previously immune to — anything from influenza to herpesvirus to bacteria that cause pneumonia and skin infections.
> So, if a person had 100 different antibodies against chicken pox before contracting measles, they might emerge from a case of measles with only 50, cutting their chicken pox protection in half. That protection could dip even lower if some of the antibodies lost are potent defenses known as neutralizing antibodies.
I am also not a fan of working with "you are an idiot and you are doing it all wrong" people. Even if they are technically 100% correct, they should have shown me some respect by having a conversation to double check their assumptions. I maybe physically robust, but I still enjoy being transported by a bus with well working suspension.
However, an out here is "time and patience". There is no way to know what all other people have on their plate, if they are tired or preoccupied with personal matters and so on. If they are being unreasonable, it's certainly worth keeping in mind that it may not be because of you.
You need to instead translate the criticism into something actionable. Always have in the back of your mind the question what to do different and when. And when responding to people, remember to respond in a way that they will want to criticize you again (it's ok to argue, but not ok to turn it back into something personal).
I don't try to control my anger at all. You're missing out on all the evolutionary benefits of sharpened memory in important situations. Stay nice and be angry with people instead of at people. Make sure they don't take it personally.
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.
Often, I'd realize that I don't want to send it at all. The emotion was processed and now it's fine.
Sometimes, there is a valid point (e.g. because someone was rude in tone) and I'd just give that as feedback in a non-violent manner.
Most of the time if someone is being intentionally rude on the internet, they're also being a troll. Don't feed the animals!
Simply not responding leads to this person bullying you and/or the entire team eventually. Unless this happens really once, which in my experience now is not the case. Some people are just bullies, not the type they come and hit you in your face, but do snappy comments, or shaming you, etc., and they should not be allowed to continue with their behavior. If your manager doesn't do anything about it, you have to do something about it. It takes bad experience to realize that, but once you understand "the game", you will never let this happen again. Just learn to distinguish between personal attack AND "PR comment" on your code, though.
Also wanted to specifically comment on
> 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 sounds very close to mindfulness meditation - or any kind of meditation really. In my opinion that is also a great way yo get better understanding of oneself and it can help improve quality of life overall a lot.
>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.
I think those two are the core of the good advice. I'm also quite bad at not getting emotional by criticism and this is what I usually do too.
I would add that it's better to throw away the idea that "after some training, eventually you won't react badly to criticism" is something you'll achieve. Some people (like me) didn't really stop reacting badly to criticism, but just found a system/coping mechanism to channel that emotional reaction in a healthy way.
Another practical advice is to write down the criticism you got when you got it. Even if you got the criticism over text, the practice of writing (summarizing) the criticism received when you're under your emotional reaction will slow down your thought-process (you write slower than you think) and you'll also have material (something you wrote) later when you're more calm. Re-reading the criticism later from the person that gave it to you, might stir the negative emotions again and start a vicious cycle, so something written by you is a good intermediate to stop that, and detach the message from the person.
Only addition that I might make is that if the reviewer has taken the time to deeply understand your problem space and reply, they have given their time and energy and in a very real sense that is a gift. (Depending on their motivation of course - maybe they do it to lord it over others... but that is not your problem - it's their problem), I try to be thankful and this for me also contributes to the sense of togetherness in a 'us vs the problem' sense.
This works well in professional settings, but falls apart in certain online communities. How do you deal with people that don't have positive intentions, but actually have the precise opposite intentions, i.e. they want to attribute any perceived problem with your work as it meaning you are a bad programmer. Not taking that personally is far tougher.
If folks are not providing constructive feedback there’s no reason to pay any attention to what they’re saying.
(The downside of internet fame to anyone is that you will attract far, far more of these people, regardless of what you do.)
Yeah... I don't consider myself to have "internet fame" but I suppose I'm well known enough in certain large communities that I've managed to attract these people. I've ended up leaving the communities where these people are active, but I have seen evidence that they continue to spout lies about me there. I often wonder if people just take what they say at face value. The urge is to stay in those communities and correct the record at every opportunity to defend my reputation, but that takes a huge amount of effort and sanity to deal with. Is the advice in these situations to simply ignore and forget?
In the first case, the community is healthy. In that case, someone spouting lies about someone who isn't even there anymore is going to look rather odd, especially if you had a history and a track record there. It has a good chance of not getting much traction, and it might get some pushback from the community. In this case you have a fair chance of being able to successfully leave your reputation in the community's hands.
In the second case, the community is toxic. The lies are believed, and even amplified by others. Your reputation there is toast. You could go back and fight for your reputation, but if you did, you'd be likely to lose, and the attempt would eat up your time and emotional stability.
In either case, just walking away and ignoring it is about as good a strategy as you can find.
Note well: I am a random nobody on the net. I don't have a reputation online, except under pseudonyms, so I am talking about what I do not actually know. (Yes, I am aware of one person online who defamed my real-life identity. They were obscure enough, and their rant was obviously unhinged enough, that I felt no actual harm from just ignoring it.)
I know enough that I can tell if it's preference (say, linting style) or misguided (for example there's some wrong advice floating around that multiple returns are inherently bad) or something I actually missed, and in that last case usually how much of an issue it actually is and whether it's a new topic to learn or something I forgot or something I deliberately didn't bother with.
If you’re part of an online community where bad intentions are the norm, I’d recommend moving on to another. Why spend your time with a group that frequently makes you feel bad on purpose?
> How do you deal with people that don't have positive intentions, but actually have the precise opposite intentions
You move on to the third paragraph. Either ignore it (that can be tough, but the sooner you let it go and continue with your day the easier it becomes) or respectfully point out the problem. Try to have them not take it personally lest they become defensive and double down. The goal is deescalation. Speak specifically to the content of their message instead of them as a person. Use a variation of assuming good intentions: assume they are normally a good and reasonable person who is having a bad day and lashed out once. Empathise. Give them an out to apologise for their behaviour and they often will.
When that doesn’t work, reread your reply. Was it respectful and imbued with good intentions? Is it clear the goal was to improve the discourse? If not, learn from it and try again in another situation. But if you feel you did the best you could and the other party is being intransigent, let it go. Feel good about your effort. Even if you were unsuccessful with that particular individual, other people reading the exchange may take something positive out of it.
Be sure to never reply in anger. That only generates more conflict and ruins your day further. There’s no point to that.
Indeed, that's precisely what I ended up doing after what has been ~3 years of trying to make the community better.
What's somewhat interesting is that it seems the community in question went downhill as soon as the pandemic started, the underlying issue was a lack of serious moderation and an unwillingness of the powers that be to introduce it and while that was okay for many years, once a critical mass of people with bad intentions arrived the environment just became toxic because they were largely unchecked.
There it is: the false dichotomy of “good” vs “bad” programmers.
No, programmers exist on a multidimensional spectrum and performance is contextual.
I would also add: consider the counterfactual where you didn't even make that work. Surely making a honestly flawed work beats the heck out of not even accomplishing that work after all.
Lots of other works are flawed, in various areas of human activity. Yes, it sucks when it happens but the only way we as individuals or as a species move forward is by concluding tasks that are not critically flawed - they don't need to be perfect.
I have a cantrip these days: "I'm going to take a minute and process that."
It can mean a lot of things, under the hood, and I've had to repeat it a few times in some conversations, but overall, tremendously successful statement.
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.
I do a lot of micro experiments, most of which don't work. But I've gotten better and faster at performing these experiments over time. The more of those I make, the more I learn, the more suitable the solution can be.
When an author makes edits on a draft, those are steps to a finished product. We're similar: our steps result in learning, and that's the most essential element of a good product.
https://starwars.fandom.com/wiki/List_of_changes_in_Star_War...
I will be the first to apologize for messing up something for someone else, or giving bad advice, or for taking a decision which lead other people down a wrong path. I'll also apologize, as soon as possible, and in front of others if they're there, if I said something that could be misunderstood or sounded harsh or brash. (Though, that really does not happen very often at all). I believe in modesty and dignity, and apologizing is part of that.
I can explain better with examples.
"Sorry for wasting your time with this mistake," feels very formal and isn't really applicable in most cases. It would be more appropriate if, say, I'd made a mistake, not owned up to it, and the lack of accountability has a negative impact.
"Ah shit, that's totally broken. Sorry, that was my bad!" is more what I'd do and it's a lot less formal. I'm not really apologising or feeling any remorse. I didn't do anything immoral, here. What I'm really saying with "sorry" is "I am accountable for making this mistake and I will commit to fixing it."
I hope this helps clarify the different meanings.
I do apologize for mistakes due to laziness, shortcuts, emotionally charged decisions and the like. Things I knew at the time (or could have known) were not the optimal choice.
"Sorry you have the wrong number" does not mean it's your fault for receiving a phone call.
Most mistakes are only mistakes in retrospect, but at the time seemed like good or at least reasonable ideas. I don't apologize if I've done my due diligence at the time.
And I'm Canadian, saying sorry is like our favourite pastime :)
That said, sometimes I'll convey that I wished I had seen things better in the past, and sometimes that comes out like an apology (eg:sorry folks, I wish I had known this tech was totally unsuitable here).
Watching this about a year ago was eye opening to me and I wished I'd found this video when I started studying in college!
Each individual piece of work separately, sure.
In aggregate, anything that doesn't average out probably points at something to work on learning.
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...
It is about the work, and how other people react to it. The impact is has on other is all that matters. Your intent is interesting, but not relevant to their reaction. So if your work does not get the reaction you hoped for, that not a personal statement about you, it is simply something for you to work on.
Day one of my first studio class, we did sketches of the person next to us and the instructor helped critique us. We learned to critique each other over time and with careful guidance.
I'd imagine no training in normal education is the problem here, not not being to art school...
That is to say, an instructor disseminates organized knowledge to the student. The student may be asked to communicate that knowledge back to prove mastery, but there's not as much emphasis on students giving each other critical feedback. Even when there is, it usually has a minor impact on your academic progress or grades.
As such, there's no incentive to learn how to give good feedback or make use of peer feedback.
Art school tends to be unique in that it cannot be taught that way. You spend years giving and receiving daily critiques and incorporating them into your growth.
The commonly accepted peer review processes we use in today's software engineering field involve giving and receiving feedback on your peers' work at a frequency that the vast majority of people simply have never experienced before.
Few people are naturally good at it, and few companies invest time into training anyone on how to do it well.
It still catches me off guard when I feel someone clenching up while we talk about ways to improve something.
I sometimes take those people through a tour of my own changes and talk through all the ways those could also be improved.
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.
Yes, this realization has also been important to me. Our personalities have relationships with so many aspects of our lives.
For example: spirituality, emotional intelligence, creative expressions, physical strength, physical appearance, wisdom, appreciation of beauty and aesthetics, and insightfulness. We find identity in our social interactions and friendships, family bonds, adventurous endeavors, empathy, altruism, and our sense of integrity. Leadership abilities, an open-minded growth mindset, resilience, perseverance, and tenacity also play significant roles. Sensitivity, conscientiousness, and our predispositions towards introversion or extraversion shape our interactions with the world, and our ambition, passion, zeal, and humor color our life experiences. Whether we lean towards optimism or pessimism, our self-confidence, our work, vitality, and self-care habits are intrinsic parts of us. We are defined, too, by our commitment to diverse causes, our independence, reliability, online presence, sources of entertainment, groundedness, approachability, friendliness, and our management of financial matters. Personal growth, achievements, hobbies, political affiliations, activism, adaptability, assertiveness, and self-expression add further layers to our identities. Curiosity, disciplinary commitment, frugality or extravagance, generosity or self-centeredness, humility or ostentation, innovative or traditional mindset, mindfulness or airheadedness, pragmatism, respectfulness, philosophical inclinations (like Stoicism or Hedonism), tact or goofiness, virtuosity or departure from traditional virtues, progressivism, visionary thinking or living in the present moment, nurturing of others, commitment to others, and many other facets of life all come together to make a person who they are.
So, where does work fit into all of this? It's but one facet of our lives, almost inconsequential in the grand tapestry.
In societies influenced by American culture (as well as others like the UK, India, and Japan), there's often an undue emphasis on one's professional identity. The question, "What do you do?" has almost become a conventional conversation opener. This, however, is a vestige of outdated social hierarchies rooted in class and caste systems. The modern, holistic sense of self that is prevalent across much of the world has also been gradually permeating American culture. But, this cultural baggage can make us fixate too much on our professions.
But we are not forced to stick around in tradition and the past, unless we want to. I certainly do not. And that helps with seeing work for what it is in our lives - just one small aspect.
EDIT: Rephrased the long list into a paragraph so that it does not take up half of the comments on the page vertically :)
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.
This is complete shit, start over.
Even though there's vulgarity, it's explicitly directed at "this" and not "you." If the vulgarity is indicative of any frustration, then it means my work was below their expectations - which necessarily implies that they have come to expect more from my work. This is confirmed by their direction to start over, without any additional oversight or specific micromanagement. The boss who says this respects you, respects your work, and knows you can do better than this uncharacteristic example without them holding your hand.
If you used this pattern in this area, it would become easier to read
"You." This comment is directed at me and the choices I made. The comment uses the conditional - it isn't frustrated, it's wistful. The language is stilted and formal; they're keeping me at an arm's length. And easier to read? Humiliating that my thought process is that incoherent.
This variable has a generic name, please make it more expressive.
Very simple present tense statement, followed by very simple imperative. I'm clearly being handled. And please? They are literally begging me not to suck so bad. This isn't just arms-length language, this is you're-going-on-a-PIP-and-we're-being-careful-not-to-give-you-any-employment-law-leverage language. If someone ever gives me feedback like this, that's a sign I'm going to get fired.
If it's genuine, why not respond with "good call, will update" or "I couldn't think of anything better for this situation - do you have any suggestions?"
Additionally, that’s not even scratching the surface for HR documentation that is required for underperformance. It needs to be blatant “you are not meeting expectations” phrasing.
This variable has a generic name, please make it more expressive
is an indication you're heading to a PIP and a firing seems to be reading a huge amount of negativity into a comment that isn't warranted.
Different cultures and work environments perhaps, but I've often written and received similarly terse statements on code reviews; it's just business as usual. As a rule, I have a huge amount of respect and value my team members - as I hope and believe they do for me. I do often (but not always) use the conditional rather than imperative tense as part of my British cultural baggage; but I doubt most people even consider that.
Edit: on further reflection, I think the better relationship I have with the engineer in the code review, the comments get more terse. You can write extremely brief things like "should be private" or "missing type annotation" because you know the baseline working relationship has enough trust and mutual respect to support comments like that without offence.
Baseline working relationship has trust and respect: "should be private"
Otherwise: "This is supposed to be encapsulated. Please make this variable private."
Stilted, formal, directive language is not a hallmark of a healthy working relationship, and the number of replies to my comment here that seem to take the opposite position... is not encouraging.
"This is complete shit because of X Y Z" is actionable "this is complete shit" is not. At what or who it is directed is irrelevant, it's useless.
> The boss who says this respects you, respects your work, and knows you can do better than this uncharacteristic example without them holding your hand.
Nope, because again, no indication why it his shit.
>> If you used this pattern in this area, it would become easier to read
> "You." This comment is directed at me and the choices I made. The comment uses the conditional - it isn't frustrated, it's wistful. The language is stilted and formal; they're keeping me at an arm's length.
Yes, "you" prima-ballerina, you wrote it, take responsibility for it.
> And easier to read? Humiliating that my thought process is that incoherent.
You should be. Code is for reading. You should know that by now.
It would be different if it was directed at junior dev but you should know better.
Fix it and move on, everyone writes bad or unclear code sometimes.
>> This variable has a generic name, please make it more expressive.
> Very simple present tense statement, followed by very simple imperative. I'm clearly being handled. And please? They are literally begging me not to suck so bad. This isn't just arms-length language, this is you're-going-on-a-PIP-and-we're-being-careful-not-to-give-you-any-employment-law-leverage language. If someone ever gives me feedback like this, that's a sign I'm going to get fired.
That's insanely weird assumptions you're making. Everyone makes bad code. Being polite is hedging your bet against how the other side answers to your feedback. If you know someone and you know their style "hey dude, this reads like shit, fix it" can be entirely enough and just fine, but if you don't know the person all that well being nice won't hurt.
Not "you named variable weird, you're fired" like you're trying to interpret it
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.
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: I'd also like to note the religious link that people have lost a spiritual connection of their self-worth[1], and in it's place have adopted a professional and materialism meaning when their professional work is criticized, so is the root of their identity.
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.
[1]: (at least in my religion it affirms your inherent value as God created and declared "Good" in design and nature, lets not turn this into a religious debate)
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.
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.
Not that that is worthless, mind; but becoming aware of that in the process is what makes you senior. By definition of it being part of growth. With time, you will have been no both ends of more and more reviews. Hopefully you start to see how both sides of the conversation that is a pull request go.
And note that you can't "policy away" bad snarky comments. If someone is giving a ton of those, or is generally tone deaf, work with them. If it is someone you don't want to work with, pull in peers to help work through that. If you don't have a support network, start there above anything. Even if things seem to be going well, having peers to lean on is important for the times that it doesn't. Learning to be a good peer is equally vital, and is a part of what makes the reviews more relatable and part of a group project.
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.
I have an attitude that there's absolutely nothing I do that can't be improved. This may sound miserable on the surface, but for me it's actually quite freeing. It has the effect of making it easier to accept that things aren't actually going to be perfect (so it can help avoid the trap of over-engineering) and at the same time, it makes it much easier to have productive conversations with co-workers about what to improve/delete/rework because the existing product is something that could be better.
The other thing to think about, IMO, is that that PR comment, snarky or not, was something someone put the time in to come up with. For you. It's a gift. I've worked in places where getting any kind of PR comment beyond "approved" or "Fix your indenting" was an uphill battle. So getting a comment from a colleague that is meant to a) help make you better at what you do and b) help you both create something you can be proud of, is massively positive. It took time and effort for them to read what you did and think of a way to make it better.
I believe that both of these responses can be valuable when handled correctly, but doing so requires a different strategy for each. Actually, the first step is the same for both: make sure that you've had the correct response: if you're sad, double check the criticism really is accurate; if angry, double check the criticism really is wrong. I think perhaps a lot of trouble can be attributed not to having one of these upset responses, but to having the wrong one! A helpful side-effect of thinking about the other kind of response is that they both mediate the other: thinking about situations/new evidence in which one might respond the other way to the same criticism alleviates the original emotional response.
The next steps are more involved and specific to each response but this comment is already longer than I meant it to be :).
- You are not your work. Try to take any demerit toward your work as 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
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 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.
“Hmmm… what can I learn from this?”
It reframes criticism from right/wrong or blame/defensiveness.
It also helps me shift out of my own inner critic’s response - such as trying to evaluate if the person critiquing is qualified enough to do so.
I’ve genuinely seen that the most intelligent & successful people I know truly believe they can learn from anyone - including people who are factually wrong.
It seems like your current reaction isn’t a choice, so that’s a personal growth opportunity.
When you feel critiqued it’s helpful to:
1. Notice how you feel 2. Express it & feel it fully - not to others, but with yourself 3. Give yourself space & support to have the experience you are having with no expectations 4. Once you feel that space, get curious about how you’d like to respond
If you weren’t treated this way as a child, this approach can seem very odd or even dangerous.
Meditation and Gay & Katie Hendricks’ work has been helpful for me here (https://foundationforconsciousliving.org/).
But mostly what has helped me is time. Learning to take care of our own feelings & choosing our responses to things around us are a part of maturity.
It has taken me years to develop these skills, but the impact on my relationships and career trajectory is very clear.
So be kind to yourself, set 1% better goals in terms of how you respond, and recognize that you are enabling yourself to become more coachable.
And, this line, double brilliant: ``` I’ve genuinely seen that the most intelligent & successful people I know truly believe they can learn from anyone - including people who are factually wrong. ```
I can't add much to this, but I'll make some additions/rephrasings
- When you submit a PR, start with the attitude "I can't wait to see what my peers point out, so I can learn from it"
- When someone points out a mistake, or flaw, or just a way to improve it.. maybe some "improved" code organization or more succinct logic, just say "Hey, THANKS!!" Be enthusiastic, appreciate their feedback, and "Opportunity" to learn. If you look at it as a "Opportunity", not as a "Criticism" then no matter what they say, you can't really be bothered by it!!! Your are uh.. anti-fragile!!
To summarize -- Don't "dread" the criticism, "Look Forward To it" -- it's how you improve, it's how we all improve.
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.
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.
Edit: I’m no expert at this btw. Recently I had a realization that I don’t like taking feedback publicly, would rather receive 1on1. I had an EM who had a tendency to do things quite publicly and I always found those situations difficult to manage. When I arranged for a 1on1 and told him about it, it turned out that he had another quite different concern and rule around doing things publicly - he wanted more transparency in the organization. After understanding each other he backed off of being too harsh, and I started leaning more in on the public channels, helping him achieve this goal.
Since I have been working in this manner people are more open to changes themselfs. It works both ways.
I've seen so much bad code and so much mess. All made by nice - and not so nice - generally competent folks in varying circumstances. Also contributed quite a bit myself, actually. ("I've seen things you people wouldn't believe")
After a while you get numb to it. There are a staggering number of ways to be right and I don't think there is a general fix other than expose yourself to as much as possible.
It's unlikely that the person making the comment is out to harm or anger you. Ideally you are both on the same team, trying to perform some task for the benefit of your employer. In that case, recognize that your ego or pride has been engaged; observe it, but then put it aside and get back to work.
If they ARE actively trying to anger your or harm your career (rare, but some people are just toxic) all the more reason to ignore the provocation.
My main challenge is when people dig in their heels about technical solutions that I find distasteful. For me that's less about how beautiful the code is and more whether it solves the problem and will be maintainable. Even here a lot of arguments can be ignored. Again, make your ego and identity as small as possible. Brace style? Tabs vs spaces? I honestly don't care. If someone wants to argue about those things I'm happy to let them win.
Be half-monk, half-hitman and get the job done.
I had co-workers that avoided me as a reviewer because I would highlight important tech and architectural concerns. Those were hand waved away with the usual "we don't have time" arguments.
They've since left the company and I've spent literal years pulling out those deeply embedded ticks.
I've come to realize that I should have asserted myself a lot more back then. You're right that many of the small things don't matter (or can be improved fairly easily). The big things: some of those matter a lot.
It can be hard for others (especially more junior devs) to see the good intention of trying to avoid future quagmires. That's been a bit of a challenge on my end.
I'm a huge fan of good interfaces with shitty code inside. You can always improve the code inside if you got the interface right. If you got the interface wrong you'll need to rewrite anyway.
But on a more realistic note - separating yourself from your work is hard. I accept that at times my code will be bad, sometimes the reasons are external and sometimes I just did not know better. But I try not to repeat mistakes, that is the key. Also I consciously frame it as “the code had a bug” vs “my code was bad”. How you phrase it goes a long way, imo.
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.
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.
Reminds me of my favorite code comment that I came across once…
“I burned one right before I wrote the block below. Now that I am no longer high I have no idea how it works or why, but it works.”
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.
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.
Remember the only way from amateur to professional is by constant improvement, which requires constant critique of your performance.
As you improve the criticism becomes less, you also have to rise above the amateurs who don't know how to adequately structure criticism, so that it written in a less personal way. Early on in your career this may seem deliberate and you will make a lot of mistakes, but it does fade.
You should also have 2 tenets:
- It doesn't matter what happens, you are paid for the code regardless, so don't hold so much pride.
- Make sure your reviews of others hold them to the same standard and language so they feel what feedback like that does and helps them adapt (it's also revenge served cold if that's your thing).
I realized this way early in life and it was liberating. Even then, I wish I had realized it sooner.
Additionally, code review is the worst time to question decisions made by the developer. You have probably put a lot of work into your changes. Someone callously tossing a "why don't you do it this other way" into your PR feels like bullshit because it is. And again, larger PRs are going to have more (and lower quality) comments, which makes it easy to feel criticized or defensive. The parts you had the most trouble with are likely the parts that people are going to comment on most.
The solution to both of these is to try and break your work into the smallest chunks you can. This makes it easy to catch your own mistakes, as well as reducing the mental burden on the code reviewer. It gives you a chance to validate your strategy before you implement the whole thing. I've never been on a team that pushed back against the idea of splitting a large task into smaller ones.
As to when you do get called out on a mistake, it's ok to feel bad but recognize, people make mistakes. The person did you a favor by finding it in review vs finding out when bug reports start coming in. If it's a good catch, respond by saying "thanks for catching it." Nobody knows everything, nobody writes perfect code.
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 try not to express this annoyance, so other people haven’t picked it up (though I'm sure it shows sometimes). It's something I'm trying to work on as suppressing that annoyance cannot be healthy for me.
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.
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.
Having people criticise your work fucking sucks. There's no way around that. Someone you respect says you did a bad job? Yes, you'll take it personally. I don't think there's any way to avoid that initial feeling. Have I read patch feedback and wished I could sink into the Earth? Yes. Do I still have intrusive thoughts about a patch I sent almost 20 years ago that was eviscerated by the subsystem maintainer? Oh heavens yes. These are entirely human reactions. It's not a flaw to feel that way.
As others have said, being able to interpret feedback as well meaning can help. But you should also try to find external feedback on whether the criticism you're getting is positive, or whether you're potentially in a situation where you're being exposed to abuse. Sometimes feelings are an overreaction - sometimes they're justified.
It’s sometimes hard to remember, but feedback is a gift. It is someone else taking time to show us how to be better. One approach to feel less bad about constructive/negative feedback is to show and feel gratitude to the person giving.
I remember I had a customer who was somewhat hostile and awkward when reporting bugs. One day they reported a bizarre issue related to a race condition and I spontaneously responded “that’s a AWESOME bug find. It’s a cool bug. Sorry it’s impacting you but I appreciate you helping us make the product better.” That and similar interactions changed the tone of our communications- by expressing enthusiasm and gratitude for the opportunity to learn I reinforced those emotions over the angst and worry over the problematic feedback and at the same time changed the tenor with the customer who went from being a little angry at finding bugs to enthusiastic at reporting then. I distinctly remember my smile the first time he started a meeting with “I’ve got a good one for you.”
If you can find a way to value the learning highly it helps reduce the sting to the ego of criticism.
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.
Letting go of the ego a bit is something you have to find within yourself.
After that, it's easy. If the criticism is about the code, either accept it or be analytical with a thoughtful "defense" of the code. It leads to good technical conversation and the code benefits from it, and either one or both of you will learn something. Learning things tends to go away the more senior you get so the opportunity becomes exciting at some point.
If it's about you personally, then it's no longer constructive criticism and thus a civil response about keeping things on topic usually suffices.
I think of this in two ways. First, in a team, we're all collaborating on the project. Different people have different ideas and different experience, and debating can make for better results. In my last job, there was one particular person I disagreed with all the time (down to hops vs malt) but for that reason was a great person to collaborate with.
Second, there's code review. My last place was very much into its style guides and best practices at the individual PR level (but remarkably bad at higher levels; the prevailing large-scale design rule being ‘ship the org chart’). I think of that sort of code review comment much like a compiler or analyzer message: sometimes it's right, and caught a mistake. Sometimes it's a false positive, and you just have to change something to make the tool shut up.
(Third, I wouldn't be able to recognize an actual personal attack unless it were extremely blatant.)
Did anyone die?
No? Then on the scale of important consequences the mistake was statistically inconsequential.
My day is ok.
In that context, what-I-like doesn’t matter.
Wise people are often wrong.
Smart people make dumb mistakes all the time.
Diligent workers still don't get to approach every single problem with meticulous attention to detail.
Rational, reasonable people nonetheless inevitably hold some inconsistent beliefs.
... and so on.
You can be wrong without being bad.
It can be hard to remember this at an emotional level, especially if you have a history of being belittled for making mistakes, or you feel like you're not taken seriously enough. But it's true! Remind yourself of it. :)
Secondly, if somebody says something that you dont agree with but is not really important or interesting, or even snarky, don’t respond. Just ignore it. Respond to another comment (if present) thay you do find constructive and interesting. This is very powerful because you actually respond to the snarky comments without responding. This can sometimes be the loudest and best response. Don’t waste energy where there is no gain.
It helps. Remember also that finding flaws is a lot easier than creating things, especially if new ideas are involved. Also remember that love makes blind; it’s easy to fall in love with one’s own ideas/solutions and so ignoring its shortcomings. The easiest to fool is yourself. But that’s fine if you allow yourself to adjust.
Finally, allow yourself to be convinced. If somebody has a good argument against your case, give them a little credit. Try to have a conversation and not a debate.
Be a Stoic. First, start with the understanding that you can only control your thoughts and emotions. You need to seek "truth" in those situations. If it was mistake by you, the comment is justified (and you shouldn't worry about snarkiness because it is due to their ignorance). People who take cheapshots don't know how world works and likely, they will face bigger issues - but try to treat them as being ignorant. Secondly, your issue may be tied to your sense of self or ego. This will take time and the hardest to master. But by being aware you will find your own way. What worked for me was to pick something totally outside my day job that gives satisfaction (It could be still be related. For example, building some open source projects or just fun projects whose quality is under my control). So I am not seeing any "approval" from anyone
(1) how do I not take snarky critiques of my work personally?
(2) how do I not take kind critiques of my work personally?
Issue 1 is often about understanding why the other person is snarky. Do they get this issue a lot? Do they realize they’re being snarky? Are they just a dick?
The goal here is to empathize so you can translate the feedback to issue 2.
Issue 2 is often about your own relationship with your work. Are you wedded to it, because it’s the creation of your own hands? Is everyone else too dumb to see why your solutions work? Are you in an area where the underlying issues are opaque or challenging?
The goal here is to be introspective + address why you have a gut reaction to the feedback. Eventually, you’re trying to get to a “reviewer and I against the problem” mindset.
All that said - sometimes it’s not a bad thing to take things personally. Recognizing when “feedback” is out of bounds is part of the process. Good luck!
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.
I'll be honest and admit that I connect self-worth with my work, or the sport I'm playing... part of my identity is the desire to do things well.
So yeah criticism hits personally for me. But actually: In a good way. I view every piece of feedback as an opportunity to advance that personal identity.
Usually at work that's desired: The people giving feedback are trying to help. But even that criticism from that stranger on the internet trying to get you down is an opportunity.
It took me a while to get here. I still have half a second of defensive feelings when I receive unexpected feedback. But I've trained myself to quickly let curiosity overpower the defensiveness.
As others have said, your awareness is half the battle. You're on a good path. I hope this alt POV helps!
That captures most of the high-value engineering work necessary to solve the problem, and you can move faster, unencumbered by programming languages, linters and toolchains because you're using freeform human communication. That document is allowed to be ugly.
Once you have an initial idea down, even if you don't like it yet, pass it around to your coworkers. Ask them for feedback on the design, especially the requirements, and ask them to help you brainstorm solutions to the parts you don't like. Your coworkers are going to naturally approach your document with a positive, progressive mindset. There's no risk of breaking things or stepping on toes. Chances are there will be design decisions they don't like, or have better ideas for how to do it. Since it's a freeform document, you can quickly rewrite stuff and tweak it until everyone's happy, or you can at least have the tough conversations to reach a compromise.
Once your coworkers have had a chance to provide feedback, then is the time to write code. Since you did that up-front work, you should be able to barf out the code 10x faster. You could even hand it off to someone else like an intern to barf out the code.
When the code goes through code review, it's your coworkers' jobs to be in a very conservative mindset, looking for regressions and maintenance pitfalls. You'll likely have a very different experience, though, because the code is now the manifestation of a previously agreed upon plan. It's simply an artifact. The lines of code are "cattle" to be slaughtered and consumed rather than "pets".
Lines of code aren't really valuable, though. They're technical debt. They're a liability. The valuable, useful thing is the final working system that solves other people's problems, or otherwise enriches their lives. The value of a software engineer's work therefore isn't the code, but it's all the design work that went into the code that made sure it made the system better rather than worse.
Whenever I personally write code without a backing design document, I consider it to be speculative, with a lower probability of ever getting merged somewhere useful. I expect any attempt to get it through code review to be relatively painful, and I go as far as mentioning the speculative nature up-front in the review summary so that the code reviewer is in the right mindset.
That reminds me of many years ago, when I did a lot of circuit design for solar car racing while in university. I developed a thick skin for technical criticism pretty early on in high school from FIRST robotics. There were plenty of fellow solar car team members that hadn't had the experience yet, and so it was often a source of inter-team drama. There's one effective trick I would use when mentoring newer team members in the art of PCB layout. After they spent 20+ hours sweating over completing their first ever layout, I would sit down with them and go through the dozen or so novice mistakes they had made. I would encourage them to share their story of personal pain, misery and self-discovery that went into the result that they were sharing with me. I would then apologize profusely as I hit the "unroute all" button, reminding them that they still had the file saved. I would then invite them to start over and do it again from a clean slate. After a few minutes of disbelief and frustration, they would get to work again. Without fail they would come back a few hours later, smiling ear-to-ear and excited to show off how much better the layout was.
Phase 2: Aware, unable
Phase 3: Aware, able
Phase 4: Unaware, able
Congrats, you're at phase 2!
I for one have developed the ability to suppress my initial annoyance simply because other people code has just taken me by surprise so many times. Just ask them to explain why it is better, for me there was almost always something insightful. Idk, maybe I was lucky but a correction from someone has really become an opportunity to learn for me. Of course there are exceptions, and then I do discuss/defend and sometime force my way. But not often.
Also: Over time "Everybody makes mistakes" moves from being "some expression" to absolute reality, by experience. So no reason to feel bad. You may just need time. And as said, going from phase 1 to 2 is already progress, suppressing your annoyance for long enough may just land you in Phase 3 automagically.
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.
2. They way we "judge" other people could indirectly be the way we "judge" ourselves. When you encountered somebody else making the same PR mistake what would you do or think about the person? I encountered a very similar humbling experience and I found out that I judged people very easily (although I didn't verbalize it) and it affected how I perceive the mistake I made myself. In my case, I learned to be more compassionate and passionate, and to judge people less based off their mistakes
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"
To avoid this, teams need to come together and learn how to be respectful during code reviews. I find this article to be a very good resource:
https://www.michaelagreiler.com/respectful-constructive-code...
When something is still a work in progress in my mind, it is much easier to have a positive attitude towards criticism and see it as something that helps me improve. There's something I can _do_ with the criticism in these cases.
However, when I consider something as done and it is criticized, I can get frustrated and defensive. It's a bigger mental leap that's necessary to make the criticism actionable.
The simple (though not easy) solution is to consider nothing as permanently done.
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.
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.
So here's the thing: management is metadata for actual work. It has very little to do with the day to day business of getting things done. The more elaborate the management system, the more intrusive it is to getting things done. A good manager doesn't look to blame people for problems - they do whatever is required to help each person solve problems, period.
So when you get blamed for things that aren't your fault, don't take that personally. It's not about you, it's about that person's insecurity about their job and need to deflect attention from themselves.
As far as snarky comments go, well... again, it's not about you, it's about the other person and their need to feel or look superior, or to make people think they're funny, or it's compulsive. Unless this same person singles you out constantly, it's probably not personal.
As for feeling bad about honest mistakes... the only mistake you should ever feel bad about is the one you keep making. Everyone makes mistakes - some of us are just better at bullshitting about it. The key is to learn from them, and what questions to ask in advance to avoid them. That's just a thing that takes experience.
Eventually you'll get to the point where you don't take it personally anymore than you take it personally if you go on a blind date and the person doesn't fall instantly in love with you. Does it mean you're not lovable? No. It means that, at this moment, that person didn't want you. Again, it has nothing to do with you, and it doesn't even necessarily mean anybody did anything wrong. That reviewer might have had a shitty day, or might be under undue pressure themselves. Doesn't make it right to use you as a scapegoat, but that's just the world. People aren't always smart or fair.
As long as they don't fire you, you'll just learn to shine it on after a while. Whenever people are forced to interact with other people for any other reason than fun, there's always gonna be friction where they meet.
As a random example, sometimes I respond to emails on a one-on-one basis, removing the dozens of people CC-d on the original so the sole recipient can quietly correct a mistake and save face.
Something like 50% of the time they'll angrily reply and add back in the original cast of thousands, ensuring that everyone is now painfully aware of their mistake.
You also should develop a supportive peer group. I cannot emphasize how important this is. You probably will not find it at your job. Find friends you admire, and try to be the kind of person they admire.
Constructive criticism should always flow freely both ways. In most professional environments, this does not happen. (Criticism flows down the Org chart.) This is an inherently toxic situation.
Keep in mind, insults can masquerade as criticism. Snarky comments are insults masquerading as criticism (though they may be well intentioned).
Work environments are tough. I have had situations where a manager far less technically skilled than me criticized an architectural recommendation, the business now deals with the consequences of those decisions (bugs, instability, excessive resource usage), and I am comfortable (bemused) because events proved I was recommending the correct decision and I have a support network outside of work. This sort of situation is toxic to improvement if you are not careful. I suspect many people find themselves in these situations professionally so often they just consider it normal.
There are many types of therapy that works with projections: https://en.wikipedia.org/wiki/Psychological_projection
Personally, i've done the work through ManKind Project, a non-profit for men's work.
(Assuming youre talking about 'work' in a professional context)
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.
* Where you work, does it feel safe in general to acknowledge mistakes? Is there a culture of humility, and the team supporting each other? Are the most skilled/experienced/respected the first to point out when they made a mistake? How do managers/leads react when learning of a mistake? Do you feel a general sentiment like mistakes are human, and that everyone i supporting each other and wants everyone to succeed? (This might not be just you, but something the company can improve.)
* Do you have a feeling about how your skills/performance relate to the needs/expectations of the team? Do you feel like you're appreciated enough? Do you feel the Impostor Syndrome? How does your current experience level fit in your team or company?
* You said "unintentionally snarky", but do you ever feel that someone is being mean, overly critical, or disrespecting? What about that being your initial reaction, and then later you decide it was unintentional?
* Do you feel like the perception of others when you make a mistake threatens your future?
* Do your thoughts seem to be mostly about meeting your own internal expectations of yourself, not so much what others think? Were you raised with high expectations put on you?
* Have you worked with a therapist/counselor on this? I'd think it'll take them awhile to get enough context about your work situation, but that's normal, and they have a lot of relevant training and experience that we don't. Your health insurance probably covers this.
* Have you talked about it with a trusted colleague where you work, maybe a trusted manager? They probably won't be as skilled as a therapist/counselor at all facets of this, but they have direct information about some of the context.
Is it actually in fact safer than hiding them?
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.
It's not your pride or your ego. Never lose your passion and don't let the world beat it out of you. Feel your own greatness in more than one way and it will improve your life in ways far greater than just the ability to take criticism. You need a playground in your life that's not connected to your paycheck to dump your energy into and make a mess.
When I send a PR the French guys especially come off very snarky, and I mean they're a pretty snarky people, sometimes guys will throw the most savage insults at each other in meetings and it always lands as funny.
Anyways I'm usually pretty good at taking criticism non personally but their pr comments can come off rough sometimes.
I'm not sure I have anything to offer that is not just an anecdote, but it does sound like you haven't really internalized that what goes on in your head goes on in everyone's head yet. I remember when I used to take everyone's words at face value and therefore feel inferior; it took me much longer than it should have to realize just how much most people bullshit all day.
You might be getting defensive, in other words, because you already felt insecure, and the source of that insecurity might be that you believe everyone around you is as self-possessed, competent and confident as they look to you.
Let me assure you that they are not, they're just as much an ape as you are.
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.
You don't have to participate in those systems. There are places where humans are treated with dignity, not made to feel small and worthless if they aren't at the forefront of every metric, or have all the answers.
Compare yourself to yourself.
Make a distinction between you, and your work. You work, for the work to be given away. To your client. To your boss. To your customers. Dont hang onto it. Let it go out into the world.
You work with many constraints; time, cost, already existing components, other people. So what you do is not fully decided by you. So neither is the fault fully your either.
How you think about your work philosophically, matters here, I think.
But the key understand is if someone criticises your work, they don't usually target you — why would you even think they know who you are?
When they criticise your work they take time to tell you why they feel or think your work could be better. Instead of taking that at face value ("shit I am bad at making good decisions") a good strategy is to take the causal root of the critic seriously, while taking the suggestions they make with a grain of salt. The former comes from a true place most of the time, the latter can stand and fall with the subjective interests and knowledge of the critic.
So think about that causal root ("user had problems to understand X") and see it as a cause to think about the state of that project.
See how it is not about you at all? It is about the project. Of course your decisions shaped that project, but isn't it possible that there are parts within that project where your decisions could have been better? Sometimes we all take decisions automatically without giving it a second thought, so a critic can be a way to provide another perspective, one that we might not have considered before — that is a value in itself.
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.
It's easier to accept constructive feedback because it's not directed in a personal way. Someone who leaves constructive feedback isn't questioning your intentions, motives, skills, or choices. They're not leaving snark, highlighting your mistakes, etc. You won't see much use of the words, I or you. Constructive feedback teaches you something and should leave you feeling better about the state of the code.
The difference between...
We should use a wrapper around this type so that...
and
Why did you pass this type without wrapping it?
Is that the former is suggesting a logical change to the code that will have a positive impact on its fitness for use. The latter is interrogating the author and has nothing to do with making the code better.
There's no need to doubt yourself so much. Don't let poor criticism gaslight you into thinking that there is something wrong with you. If you're responding to PR feedback in an emotional way it's a sign that you're trying to protect yourself and there's a reason for that reaction. If there's a problem with the magnitude of your emotional responses, that's a different problem (I've worked with people who were not getting therapy for their anger management issues). However anger, resentment, etc are normal feelings and are useful.
The next step to dealing with it is learning how to be polite and assertive. Once you can identify feedback that is not constructive you need to learn to tell people so and divert them away. In other words, how to tell people to take a walk without telling them to take a walk.
And you can be proactive in this too: talk with your team and team leads about feedback and develop a code review guideline to enshrine some simple rules that nudge people towards giving the kinds of constructive feedback you're looking for.
And if your team is encouraging the kind of environment where you feel bad about honest mistakes then you should consider looking for another team if such discussions don't change anything.
"I don't think I understand this completely, can you tell me <interrogative>"
If the level of trust in a team is high enough that asking such questions is genuinely considered honest and useful then most people ought not to be feeling bad about honest mistakes or characterize feedback as, "snarky," and feeling anger, shame, etc after a code review. If people like these kinds of questions and it helps the team then maybe it should be in the code review guidelines.
For me, I have a hard enough time discerning the intentions of other people. Guidelines remove some of that ambiguity up front so that I can safely assume people are being genuine and it is obvious to everyone else, and me, when they're not.
However, the spirit of the idea is that code reviews shouldn't be leaving you feeling bad about yourself and the mistakes you've made. That could be a you problem but I think it's more common for us to self-doubt than to realize that perhaps the problem may lie with other people. Imposter syndrome, DK, etc, etc all seem to run rampant.
The difficult part is to make myself take people seriously when they criticize something I did.
For example, I had a boss who didn't like that I used Emacs and tried everything in his power to get me fired because of that. He would change the text of the ticket I worked on the last moment to look like I haven't done what was requested, or deliberately assign me to worthless / tedious manual-labor kind of projects, specifically assign me to work on various design / documentation documents which were stored in Perforce in MS Word format etc. I could quit any time, but the thought that he'd suffer more from having me around than I would from having to deal with his antics won. I realized that watching stupid people suffer as the result of their stupidity is kind of fun. Also, I got paid to do nothing of value. That was ironic, given I could actually do quite a bit for the company I worked for. But, hey, I bought myself a very fancy bike eventually, when I decided to move on, with all that severance money!
When my brother was in art school many years ago, he asked me to critique his work. After a few polite comments, he explained that I wasn't being helpful and the end result would be better if I didn't hold back on brutally ripping it apart. That mentality has stuck with me. I want people to tell me if my code is crap.
When you are passionate in the work you do, invest time and effort to completing work for someone to find flaws, it's hard to not be offended and take things personally.
But as humans, we are able to learn. You made a big step in being aware that you are taking criticism personally. From here, you need to learn to disassociate that what you contribute is not a byproduct of you as a person. It is a byproduct of the ask, a byproduct of your knowledge at that moment of when did your work.
To shift your perspective from immediately seeing feedback as a personal attack, practice gratitude. Be grateful that someone else took time from their busy day to look closely at your contribution and provide feedback. Sure, its their responsibility, but they invested their time to review the contribution and provide feedback that you did on your time. Sure, if the feedback is snarky, ask nicely to reword it for next time.
Third, take advantage of every opportunity as a learning opportunity. Maybe you will learn something, maybe you will be more aware of a specific type of feedback next time you are contributing, that you will try not to repeat the same error.
If people could read my thoughts, half the time they'd think I was insane, but I know they're insane too :D
It is short term vs long term thinking.
Do you want to feel good for ~ 1 minute, or for the rest of your life?
Just pause, and think, before you answer. Pretend your mother, father, or your children are in the room with you, and you'll do alright
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 find that I naturally frame myself reading comments of my work as being inherently "with" the person. Think of it like watching a movie with someone, you both can comment on the movie you're seeing, and you naturally see yourself either agreeing with their critique or forming your own critique based on it.
In the same way, detach yourself from the work, and instead view your work on equal footing with your reviewers - this naturally leads to a more objective view for everyone involved. Reply not to their criticisms of _you_ but to whether you agree objectively or not, or perhaps suggest a different way they can look at the work. Oftentimes, after reading someone else's critique I can be self-critical in a way I wasn't before and it will lead to me refactoring a bit in response to my new perspective on my work, instead of completely taking their critique at face value. Use it as a perspective shift, but don't take this method as a way to lower your self confidence and give in to critical feedback.
Now I'll admit what I have more problems with is when someone clearly doesn't "get it". I'll bend over backwards trying to explain my rationale, when often the right thing to do is to try and understand what about my content caused them to be confused. Now of course, some people just plain don't get it right away and you should always feel free to defend your ideas.
As for snark.. defuse with humor. It's not always intentional, I've unintentionally come across this way (if you haven't you're probably holding in too much feedback!) so feel free to quip but don't go tit-for-tat. Try and cut through to the core of their feeling about *the work* (read: not you) and address that instead.
Use that bad feeling to be self critical in a new way - it's a lesson that leads you to read your own work more carefully before putting it out. It's painful, but ultimately for me it has been positive reinforcement and has actually unlocked increased levels of self-confidence for me.
Every time I put out a piece of code with a strong view, or say something in a meeting, I stress about whether it was silly or just plain wrong – and I immediately go fact check myself on it to appease that anxiety. I've worked with many folks who do not do this, and they have a bad habit of making wild confident statements that turn out to be misguided or wrong and it's often too late when that is discovered. Use the feeling to your advantage instead of running from it.
This is a fight worth having because the more you do it, the better you get at it and you feel less and less attacked you feel when criticism comes your way.
The first few times doing this are the hardest. But after doing this for some time, I rarely feel criticisms are personal anymore. This also affected how people talk to me, and they make it less personal. It's an odd combination of success from both sides.
A key point to all of this, was I needed to make my criticisms less personal.
A manager told me a key point in a private conversation once that help me change my attitude.
He said "I don't like talking about people, I like talking about processes".
I had just been critical of a "person" in the conversation, and I realized how much easier it was to talk about a "process" with my criticism after I took his hint to heart. And others took some time to follow my lead on this, and for me to be consistent about this change of 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.
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.
Incorrect code is incorrect. There should be no ego there. Either in pointing it out or in correcting it. It could be incorrect due to many reasons: faulty assumptions, misunderstood requirements, etc. It's important for people on both sides to realize this is a mistake and they happen. Any single mistake is not a condemnation of an entire person. Let he who has not crashed prod throw the first stone and all that.
Then there is code that is technically correct but needs to be altered for other reasons. What those reasons are and how they are approached are important.
If it's a pure styling issue, first hopefully you have a linter that handles all of that. But if you don't, don't sweat the change. Having code look uniform is important. How they choose to address this matters more. The implication that people who use anything but "the chosen style" are inferior is a bad way to approach the issue. It's simple enough to say "We do it like this here for consistency".
If it's matter of altering patterns or what not, that could be a discussion. Did you do MVC in an MVVM shop? Did you adhere to neither? Do you prefer delegates to closures? Stored procedures vs inline SQL? Any of the vices to any of the versas. In this one, you can make your case. Maybe you have the right idea. Maybe your approach is better for this project. Maybe you win the hearts and minds. Maybe you don't. This you have to let go. And once again, it's important that no one approaches it from the perspective of "idiots do it the other way".
Basically, as long as they are criticizing the product and not you, it's fine. You aren't perfect. No one expects you to be. That's why we have reviews.
In the case of a snarky comment, I would assume the reviewer has some personal issues. I feel bad for them, not me.
A honest mistake is not really a mistake. I would do the same thing again if I were in the same situation. The fact that I couldn't have known about it is someone else's mistake.
Maybe dig a little deeper why you feel bad about it: Do you consider your self-worth lowered? Do you worry how others think of you now? Trace your bad feelings to a reason as specific as possible. Then figure out if is actually true. For example, you made an honest mistake, a team mate pointed it out in a review, and now you think the tech lead considers you a bad coder. If you dare, you can directly ask the tech lead. Just thinking about it might already help you realize it is silly though. Ok, to be honest you could realize that it is actually the case that your tech lead now hates you. That is still progress because now you have a concrete problem instead of vague bad feelings.
If it's invalid criticism:
If it's from someone whose criticism matters: pursue the criticism and reach the truth through reasoning
If it's from someone who doesn't matter: ignore, make stuff
If it's valid criticism:
You learned something. You could have continued doing things the wrong way and been worse off for it. You are in a position where someone cares enough to look at your work and take time to give you feedback.
I would add a few things. At work, try to contribute to a culture of not referring to work or ideas as being “owned” by a specific person. This can reduce prestige. For example, avoid “Molly0’s PR” and prefer “The PR molly0 opened”. It’s in everyone’s interest that the PR is as good as possible. The person who opened it hopefully didn’t do so for their own personal satisfaction, but because it contributes something important to the codebase.
What I find most challenging is when discussing different points of view on a subject, rather than eg fixing obvious mistakes. That is, if two people have very different ideas about how best to approach a problem, and start to argue about which approach is better. It can quickly turn personal and prestigious if you only point out perceived flaws in the opposing suggestion. Try to see the different perspectives openly and again, avoid thinking of competing ideas as a competition of people.
After a few months working under him, I started wearing out and started taking it personally. I started attacking him back. Not only did that cause friction between us, he gave me a bad performance review rating. I didn't give up and kept resisting one way questioning. I reminded company pays him for providing solutions and answers when his team is in need, and not sit there asking questions.
A friend of mine understood the pains I go through, and suggested I read the book, "How to master the subtle art of not giving a f*ck". I can say I am now at peace and don't care a sh#t about most things. I am still employed, but stopped worrying and taking things personally.
Many people would hate a manager who only gave solutions, often described as micro-managing. Here we have a manager who seems hated because he only asked questions.
I can see how a manager never providing actual guidance could be very frustrating though! I do recall a similar situation in the distant past, and in that case the manager was completely out of his depth and could do nothing but bluff.
I'm curious what tone your reviewers are taking?
It takes while to develop a good tone, as a reviewer, too.
Assuming your manager isn't doing the review, bring up some of the feedback with your manager. Tell your manager you're looking for technical help. Don't act insulted, but if the tone of the feedback is really off, it will show.
Senior and more evolved answer is you separate yourself from your work, "you are not your work". So someone critiquing your work doesn't mean their critiquing you.
More senior answer is that you are not attached to getting the best answer yourself, but more attached to getting to the best answer by any reasonable means (including someone else s*itting on your work).
Ultimately, you are trying to arrive at some truth, which you have produced through the lens of your own conditioning, someone is trying to provide what they think is the truth through the lens of their own conditioning. Behind it all we'd like to think there are good intentions which are all to aspire towards the truth but that when we express this idea and it gets "colored" in some sense by our own impressions of the world, it may not always come out the right way, and so you have to take a deep deep breath, to let it all just be, and press on.
But think about why this is common amongst engineers, the consequences seem to matter. Software engineers initially get clout from being right, that devolves into criticizing other engineer's code while the usefulness of being right tapers off very quickly. Many of engineers got into the trade after being told they were so smart and intellectual, and this incentivizes being correct and making correctness your whole identity (to the annoyance of others and all your interpersonal relationships). But this is not productive, there is a limit to the utility of this. When you get criticized by another engineer it might seem like there is a consequence, but often there isn't.
One way to combat this is to ask yourself what game you're in:
Are you in the money game? then perfection doesn't matter, you can make the most barely functioning antiquated software that powers the government and fortune 500 companies, and be protected by the state for your own fuckups.
Just remember that.
First, I don't treat my code as an extension of myself. My code is not me, and criticism of my code is not criticism of me.
I love a good solution, and I write good solutions, but all things created by humans are flawed, and therefore everything I make will be flawed. If somebody sees something I didn't, it's not because they're necessarily better than me (though they may be), but they have a different perspective. Often, it's something I would have seen if I was in their position and not so close to the code myself.
And because of this love for a good solution, I've trained myself to have a love for good criticism. Every piece of criticism is an opportunity. You are not perfect. You have room to grow and always will. Criticism is potentially a door to this room for growth.
Just internalize the mantra of self improvement. "I was wrong" is a wonderful thing. It means the same thing as "next time, I will be right".
Can you look 2-3 years back at your original code and not find any problems? Then that's a problem :P We all learn, evolve, and improve, so at the end of the day, any feedback is better than no feedback.
I have been privileged to exist in area where a lot of feedback to my projects comes from informal means. Friends taking a look at projects or just giving me time to think about issues. This has led to improvement that may not be as efficient, but was more meaningful.
Importantly, a lot of the feedback was positive. Perhaps overly so. It almost always remained positive, even if my code was shit. This doesn't mean I don't recognize when there are bad smells or practices. It didn't spoil me into thinking all my code was great.
I've made careful and deliberate choices to follow that practice of feedback with others and in other spaces.
So that's cool I guess. Others may have other criteria that are important. Sorry it doesn't explicitly answer the question, I just wanted to offer that.
So, what changed/helps:
1. I do a weekly therapy session. It doesn't have to be about or related to work, but I noticed that my propensity to take things personally tied to many other broader issues in how I was raised, grew up, etc. It's probably not happening just by chance. Sorting through my broader mental/emotional balance really helped.
2. A lot of folks have the impulse to react and interrupt when receiving feedback. I think, instead, it's easier to simply let that person exhaust their comment to you, and then take a moment collect your thoughts if you actually need or want to respond, which takes me to my next point...
3. Have a framework for deciding whether that feedback is worth it. You don't need to respond in the moment with any particular comment other than to say "thanks." Never write something out and send/post/etc. immediately without taking a step back, re-reading, and calmly evaluating how appropriate that writing really is.
You can then dissect your feedback with a series of questions to understand if the feedback is worth ingesting or not, like: - what can I learn from that feedback? - was that person stressed about something when delivering feedback? - was I stressed when delivering feedback? - how important was the topic relative to the broader goal or priority list of the company? - Etc.
4. Everyone makes mistakes. Even those people you're thinking about in your company that don't. They make mistakes too. There's lot of subjectivity in mistakes as well, which is another way of saying that no one is perfect. The best way to deal with mistakes is transparently own them and then move on rather than dwell - easier said than done - but effective.
- one of my co-workers setup CI automated formatting/style checks (i.e. PEP8, mypy, isort, etc.)
- much more extensive guides on how to contribute good code with many generalized examples as well as do's/don'ts. When new nitpick comments come out in the PRs - the guides were updated to avoid future nitpick PR comments
After some initial pain - we really haven't had issues with PRs anymore whereas before it was pretty painful. That said we've been working together for quite a while now.
I think a lot of times the original author may have something in mind w.r.t. the codebase/architecture/formatting/schools of thought and expect the others will pick up those ideas naturally and they get frustrated when other team members don't.
The other team members being code commented to oblivion get frustrated with what seems obscure, snarky nitpicks.
By making stuff explicit upfront - people can self help/self correct/self edit before the PR is even generated.
- First, allow yourself to feel whatever you will feel. This is unavoidable. Let it be. Not only you are not your work, you are not what you feel.
- Also, recognize that no right decision can be made in a state of anger. So if you are feeling any negativity, you must postpone whatever decision you have, writing an email, or any other (within reason of course).
https://www.observationalhazard.com/2020/11/on-taking-critic...
Take all criticism as a learning opportunity.
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.
You can’t, and shouldn’t blunt or callous yourself to criticism, after all it’s the important feedback that you get from your environment that informs where your attention should be for learning or applying lessons learned.
Rather, the key task now is for you to increasingly categorize and label this feedback in ways that allow you to appropriately evaluate whether the feedback is valid and perhaps does require introspection.
The more you can evaluate things like this, with curiosity as to other reasons that may be contributory, the more you’ll realize at least in my experience that “it’s not about you” in most cases.
Finding that saddle point of anxious introspection and detached boundaries tasks a while so, be patient with yourself and give yourself grace. I know I’m still working hard on it myself and I’ve been in senior leadership a long while now
When people criticize you, how do you feel? “Bad” is not an emotion, it helps to be more specific.
Do you feel the way you do way because you’re unhappy with your own performance and you wish it was better? Or because you’re unhappy with the other person’s unnecessary (or unkind) criticism of your innocent, honest mistake?
Or other reasons?
Often these kind of personal investigation questions can help. You may get clarity. Once you figure out clearly what’s there for you, try the same “why approach” on the other people involved, in your own head, without asking them. Why did they say what they said? and how did they feel at that moment? And why did they feel that?
If you find it hard to know a reason, try using your imagination.
Maybe there are insights that you will arrive via this process that will transform How are you see it, and that’ll help make everything seem better for you.
I hope you figure it out and get some peace. :)
I found criticism was difficult because it came as a surprise. It seemed to me as if the person giving the critique was using criteria that I wasn't made aware. This felt unfair.
The surprise, not the criticism itself was the struggle.
my solution was two-fold:
1. Eliminate the surprise by "shopping" my work around early and often for feedback. 2. By doing step 1 I would learn the "hidden criteria" that others would use to judge my work.
At this point I am rarely if ever bothered by criticism. Since I ask for feedback early when I don't feel "done" there is nothing at stake. Early criticism doesn't stick and just feels like we're working together on a solution.
If you go up the mountain and work alone, for a long time, criticism will feel worse. I do the opposite. Might work for you.
An old creative director I knew used to say, almost like a mantra, to the entire group as work was being presented and judged that ‘we are on a journey’.
If you don’t think about it, it could just sound like wanky media BS. But it’s not.
It’s about kind of surrendering yourself to this journey and that being what’s important. Don’t worry about a few mis steps or failures here and there. Leave your ego out of it. We’re still all just on the journey. It’s also about not getting too obsessed with knowing exactly where you’re going. You will figure that out as you go based on things going right or wrong.
I find it a nice way to think about doing anything creative.
There is a quality assurance approach or theory from W Edwards Deming that needs to be absorbed by institutions, and it’s that everyone is trying to do their best job and it's the machinery that is getting in the way or creating barriers. Most errors arise from processes but anything in an organization could potentially get in the way. One role of a manager is to work to remove these barriers.
You should demand any negative feedback provided is specific and try and see it as someone taking the time to try and help. Given that someone is trying to help, ask questions you can use to improve things and see the feedback giver as a person who has knowledge you lack and can gain.
You also have to be prepared that you will get unskilled feedback and that is a different opportunity for you to stretch leadership muscles.
Is that what you mean?
Otherwise I have to disagree.
Let me try and give you a simple illustration. So imagine you’re a new manager at an ad agency and you task a team of writers with developing some ad copy. You get the documents back and they are filled with typos. The writers are all professionals with experience and training. So you have to ask yourself, in assigning the task did I develop a stable system of copy development? The result is a major amount of rework and may increase the cost of the project or delay the deliverables to the client, so no this isn’t a stable system of production. So as the manager you need to look into the causes of failure, perhaps it was unrealistic timelines, a lack of a dictionary for use by the team, or a lack of internal process the writers should use like proofreading their work before submitting it, or lack of training on effective proofreading. There could be a number of barriers in the system that are getting in the way of quality goals that as a manager you can address.
Of course, some people are in the wrong job or incompetent and that’s another story, but Deming argued that most problems in organizations are caused by poor management and faulty processes, not by individual workers. He advocated for a systemic approach to quality improvement that involves everyone in the organization.
Maybe even write a letter in defense of yourself to the critic, but never send it.
Take a few deep breaths, and when you’re ready, move on. You’ll have dealt with the feeling but you won’t have ruffled any feathers.
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.
Accept that you might be wrong. Welcome anything that can help you toward the task being done right and be thankful.
Of course, if you can avoid being wrong, do. Because you can't always afford being wrong. (in some professions, it's a life or death sentence for someone)
When I started checking with others how they interpret it, they always saw it as neutral or constructive. So my assumption of the senders state of mind, influenced the way I perceived the feedback text.
For me it really helped to "baseline" with others and/or often just ask the sender what the intention of the criticism was. Get into an analytical state of mind and figure-out what the intent behind the criticism is. If could be that it's made with the best intentions and can help you get better at what you do.
This lets you more easily see what people are trying to say separate from how they say it.
Classically, programmers tend to be both not very sensitive towards how they phrase feedback, and fragile wrt. criticism of their own work. So many programmers work alone because of this.
I would say don’t judge yourself too much. You don’t have to be perfect (especially if you are not, and nobody is). You probably are in this business to learn, so give yourself some room to learn a bit (or a lot!) more. People that criticize your work may be wrong. Don’t take their criticisms as absolute truth. In case you feel they may be right, drop your ideas right away, ruthlessly steal theirs and make them yours. This is how you don’t get stuck in local minima. You don’t have to care about having been wrong, there are more constructive things to do.
I’m only partly being snarky here. I think constantly about how I should improve past code, why I shouldn’t have done x, etc. Self criticism is healthy and takes some of the sting from external criticism.
Beyond that, I think “lean into the punch” is an affective strategy. If someone says my code is crap I can either 1) fight them and try to explain, justify etc or 2) say “you’re absolutely right”. 2 takes less energy and deflates most reasonable people’s criticism, esp in person. Of course if the criticism is wrong then that’s harder and maybe not even appropriate. But even then, framing it as “a valid criticism, but Im balancing that against X” helps the person feel heard and likewise more likely to hear your reasoning.
For me, the biggest thing though is trying to have a learning or improvement focused mindset. Understanding that most comments and every mistake you make are a step in a direction where you've learned something and gotten better. You, the codebase and the reviewer are all better for the experience.
Also - it IS okay to feel a little bad or frustrated when you've done a piece of work you're particularly proud of and it gets a lot of criticism. It's important to keep the above in mind, but it's also human. Don't feel bad for feeling bad. Just try to regulate it, and remember it's for the better of yourself and everyone.
I propose this change in attitude: this is a part of you, accept it & learn to use it to your advantage.
Some people don't care when they're criticized, some do. Who performs better at a task: the person who doesn't care or the one who does? Use this desire to not be hurt to fuel you to improve yourself (you've already started with this post, i'm just redirecting the energy.)
The other thing to be aware of is to make sure you're not blaming the other person for the bad feelings. Your feelings are a signal to you, a signal that something is wrong and that you need to do something to fix it.
It sucks at first, to be extra sensitive, but in the long haul it is an advantage.
I've been working for a long time now and I have learned the hard way that nobody is perfect and nobody cares if you are perfect, in fact people tend to prefer those at their own level (not perfect), but most of all relationships matter and are probably the most important part of having a healthy and enjoyable career.
> feeling bad for honest mistakes.
Use it as an impetus to get better. If you make the same kind of mistake repeatedly how can you modify the way you write code to not do that anymore. There is a popular saying "the worst code I know of is code I wrote six months ago", but if you aren't analyzing and improving (not just changing), then it will be just as true six months from now. Code from the previous month should be better than the code from two months ago and so on, otherwise you are chasing fashion and quality is stagnating.
I used to struggle with this like you describe, and still do to some extent, but I think the fundamental cause is just insecurity, at least in my case.
I just have to remind myself that everyone makes mistakes all the time, and that's why we have code review. If someone spots a mistake in my code in review, they just saved me from looking even dumber down the line when something breaks in prod. I've also learned that feedback from others is the single most powerful way of identifying holes in your knowledge.
Over time, by forcing myself to look at things in this framing, I've come to mostly enjoy constructive criticism, and see it as an opportunity rather than be offended.
All code sucks, your job isn't to make great code it's to make great products and do your best to reduce the stress on your team, code quality will follow but first you have to be honest, open, and compassionate and sometimes a JR will take that personally and that's ok, eventually they won't or they will find out this industry isn't for them.
I find this last part helps me integrate the feedback by effectively running little simulations of how I could have taken a different approach. It seems to deactivate the otherwise prominent memory of the embarrassment of a bad review by replacing it with memories of the simulations. I have a terrible habit of ruminating over incidents from decades ago that my mind has tagged as shameful even though they’re objectively irrelevant… Thinking about detailed steps for different approaches and building associated mental images seems to help divert the shame tag.
Sure, there's always going to be assholes and people that are just straight up mean for the sake of being mean, but in my experience those types of people don't last long anywhere because nobody wants to put up with their shit.
That being said be careful not to go too far with it. People are only humans, in that they have their own interests, flaws, play power and status games and so on. More often than not criticism, even when it appears to be constructive, it's just a jab at you, especially if it's delivered in public. Nobody's work is perfect and hindsight is 20/20. Take everything with a grain of salt and be careful not to undermine your position in companies or your self image by being too welcoming about criticism.
I always second guess and ask for more details, because the person might just be misunderstanding me and I don't want to act on a false negative feedback.
I also make sure to tell them that's like pair programming for life, that the person making the critic is helping me, that I like it and I also tell a funny story to make them comfortable.
I tell the person that when I was in the army I had big angry men with guns screaming insults at me, there's nothing they can say to me that I might take offense.
Give me feedback please.
Therapy and medication can help. If you think this might be in play it is worth talking to a mental health professional.
https://my.clevelandclinic.org/health/diseases/24099-rejecti...
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.
However, some people who criticize excessively do it for not entirely altruistic reasons or they lack the emotional intelligence to understand when they are breaching someone's limit of tolerance. Even valid criticism should bear in mind quantity, frequency, and severity of impact on the individual being criticized. I think most people who are being thoughtful in the moment will do this, and try to suss out someone's limits and temperament before unleashing a volley of criticisms, but there are some who use such learning opportunities or their position of authority to vent their sadistic urges, or they simply do not understand healthy boundaries and just criticize relentlessly regardless of impact or effectiveness. I strongly believe that this latter category should not be normalized or accepted.
So you've got to ask yourself, are the people criticizing your code probably doing so with the intention to make you better, or the team better, without undue malice? That's usually the case. Try to focus on their intent to help you do better instead of the disappointment of the criticism itself. But, if you've found yourself in the unfortunate situation of being carpet-bombed with criticism maliciously you don't necessarily just have to put up with that and it would be a good idea to try to find an organization with healthier communication. People who have been in such unhealthy environments before (or had unhealthy family environments) will likely overreact even in healthy environments later, and it can take some time to learn that not everyone is out to get you, they just want you to do better next time.
What a strange idea. Or maybe not. I always thought of "feeling bad" over my mistake as a way I perceive the brain doing processing of negative learning feedback. So, "stop feeling bad" equals "stop learning" to me. Now that I think of it, maybe there's a way to detach processing from feelings, but I'm skeptical.
Feeling of accomplishment when you've done everything good is too sparse and not intense enough for me.
As for "not take that personally" I have no suggestions. I naturally presume that people care about code and not about belittling me (until there's enough evidence contrariwise).
It's another to feel shame or unworthiness, especially if that's being loudly injected from an external source.
The former can be a good impetus for learning and growth. The latter is the opposite, and can build such that it can make a negative impact on your overall growth trajectory.
I have co-workers that are able to deliver constructive feedback in such a way that I only feel curiosity and a desire to improve things. Often there's no bad feelings present at all. Much of that is also dependent on my state of mind too.
It's something I'm still working on and as others have said, having worth outside of your career or outside of others is a big portion of my ability to work through the emotions. But while I'm still learning that, I really have found power and stability from letting that emotion pass before responding
1) is the person honestly just trying to help make the codebase better?
2) is the person wording it in such a way that doesn’t insult you?
3) what is your preferred way they would’ve made their comment, if any at all? Is it reasonable for you to have that preference?
4) what are your thoughts when you receive good faith, non-insulting criticism, and why do you have those thoughts? What is the underlying emotion you’re feeling that’s triggering that kind of thinking? What are the justifications you have under those feelings & are they reasonable ones?
Breaking down why you react the way you do, and all the aspects of that interaction, will help a lot in figuring out how to feel less defensive over it.
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!
Receive -> Repeat out loud -> Think (take your time) -> Feel -> Filter -> reject/accept -> Respond
Respect other peoples opinions and try to think deeply about them prior to feeling or reacting to them. You may find a significant insight.
Pauses and slower talking receives more respect and comprehension in general.
Defend your work with the sandwich method. Acknowledge and repeat the feedback out loud. Insert a long pause and genuinely think about it. Filter your emotion and identify a logical reason the feedback offends you. Reject or accept the feedback and close with appreciation.
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.
It dawned on me that I was feeling like my own value was bring questioned when I was criticised. The material reality of whether I was actually being criticised fairly or if I even believed it was reasonable to be criticised didn't even factor in. In short, I was having an ego panic.
The fix was unfortunately just a lot of patient introspection. Why do I feel a certain way? Why is one thing my first response instead of something else? Do I like that I do that? Those were the REAL issues. Being contradicted just highlighted it.
Best of luck overcoming your troubles. I am sure you will succeed if you are diligent.
I am currently writing code that I think is, from a design-perspective, completely wrong. But I've learned to completely disassociate myself with what I code. I'll do the best that I can to accomplish because THAT'S MY JOB. That's how I frame everything. I will protest, I will point out flaws, but once the dust has settled, if my boss says she wants it a certain way, I'll do it. I'm happy to just be coding and if they don't want to listen to my advice then I'll just do what I'm told, go home and enjoy the money that I make by doing the things I want.
I think the second sentence is true for everyone's code and that's what makes the job interesting.
Also jobs rarely aim for perfection, they aim to create value efficiently for the business. If the best way of getting there is producing code with a few mistakes that are when later picked up in a code review then that's fine too.
If this resonates with you at all, then when something annoys you repeating to yourself "It's just code" might help. Best of luck!
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).
The problem is that most people take criticism as if you punched them in the face. If you never criticize another person or thing ever again you'll be way ahead in life. Polite people will never help you, but here's the problem. Your enemies will also not help you. "Never Interrupt Your Enemy When He Is Making A Mistake"
So imagine the rather unique individual who will actually give you criticism. It's the most wonderful thing to experience.
"Love your enemies, for they tell you your faults." -Ben Franklin
For dealing with snarky or nasty criticism of you or your character, I would highly recommend listening to recordings of Marshall Rosenberg's books and/or seminars on "non-violent communication" (available on Spotify, Audible, etc.) The NVC philosophy is absolutely game-changing: it's to change your focus away from the "jackal comments" and empathise with the human needs underlying them. It's God's work -- connecting and healing for you and your critic.
If we can delete vast swathes of stuff I wrote last week or last year because something better comes along or we just plain don't need it any more, awesome.
Code is a liability, shipping a working product to the best of our team ability is important and (honest, well intentioned and useful) criticism is one good way to keep learning.
So what you produced in that maelstrom is really just a reflection of the moment, not of you.
This also helps me not judge other peoples' code. I only see the outcome (the code), not all of the inputs so it's hard to know if this is good work or not in a "is this person good at their job sense" (though obviously there is better and worse code).
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.
Yes, there is a bit of a sting when you put up a PR or a design doc and your teammates basically roast it, but then there is a prideful "oh yeah, I'm someone who doesn't take any of this personally."
It's part of being an engineer, working in engineering culture. It's not personal, and it makes the codebase better. It helps to remember that your goal is the long-term health of the platform, not a little bit of your PR that you thought was clever.
It also helps to avoid toxic teams. In a good team, feedback is offered objectively, without judgement or attack.
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 main criteria for code is does it work and some try hard will always want you to over engineer the simplest of tasks, let them have it, who cares. You should not let your job define you and be your whole identity.
Be passionate about your own projects, don't hang out with coworkers in your spare time and never attend a christmas party without overtime pay.
You are not your job so why care about PR comments.
It's not a flaw. You're learning. Don't judge the sapling as if it's a full grown tree. For me, acknowledging my "bad" feelings was the thing that helped me deal with them constructively the most.
Even better, talk about them with peers you feel safe with. Say "your comment brings up feelings of... In me." instead of "you make me feel...". With the right person, that's a doorway into mutual understanding and reframig the experience for yourself.
Everybody has these feelings, you'll find out.
Make deliberate decisions.
When receiving feedback, start by saying internally, or even verbally, I realize that I’ve made a mistake, and I’m thankful you have my best interests in mind and feel comfortable enough to approach me about it. I tried my best, but what did I not understand correctly about the problem I was supposed to solve, and what would have you done instead?
No, feedback is someone else's opinion - don't assume that it's absolutely correct, listen to it and weigh it up and then decide if you agree with any of it.
You have to be able to accept feedback without taking it personally, but you should always be objective about it.
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.
1. Work to separate my personal identity from my work. This is really hard for me and takes regular reflection and work, but over time it is possible to separate the two.
2. Frequently remind myself that everybody makes mistakes, it is simply part of being human.
3. Practice humility by welcoming the feedback and expressing gratitude for the ability to learn and grow. A little self-deprecating humor doesn't hurt either, and can soften the intensity of the feelings associated with receiving criticism.
Best of luck in your personal growth journey
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.
If you're making mistakes and feel bad about that, create a checklist and go over it before you ask for reviews on your PR.
If people leave criticism on your PR, ask them how they would do it!
If people point out mistakes, ask them how they would avoid making those mistakes!
If you feel personally attacked or criticized on a PR review you should present the situation to your manager and get an unbiased opinion from a 3rd party.
Comments and discussion are for the code, not you. Don't make it about you. Focus on collaborating with your teammates.
Ultimately looking at your overall performance (rather than individual bumps up and down in a short period of time) is the way to put employees at ease.
You can't fix how your employer measures and enforces performance but you can learn to evaluate your own work in stretches of 3-, 6-, 12-months rather than at the granularity of a single PR or a single mistake
Remind yourself that their feedback, whether it's warranted or not, is just a part of the process of finding the fit within a team. Over time you'll develop a relationship together and find common ground. Try to develop trust in each other, adapt to each other. That will make it feel less bad, and help you write code in a way that your team mates appreciate (even if it's not your preferred way).
2) Compare the submodalities of that to the submodalities of something you do take seriously.
3) Change the submodalities of the latter to those of the former. You will no longer take it seriously.
- - - -
What are submodalities? Qualities of modalities.
So what are modalities? Jargon for the subjective experience of the senses (visual subjective experience. auditory subjective experience...)
Our subjective experience has a structure, you can deliberately change the structure to change your subjective experience.
It's actually pretty easy once you get the hang of it.
There is a meme gif that sums this up perfectly
The gif in question has two figures discussing a 6 on the ground which is 6 from one person’s perspective and 9 from the other person’s perspective.
2/2) “I never make predictions, especially about the future” aka Acceptable choices at the time
If you did good work, and operated with as many of the facts that you had at the time, then that is a great outcome.
Not all the facts are known. Even when all the facts are known the choices may be a coin toss. Do not beat yourself up if a choice did not work out
2. Is this suggestion a good one? Then I will use it, regardless of how it was worded. Is there something to disagree with? Let's talk why it's a bad (or good) idea.
3. Having feedback is better than not having feedback. Or being in a situation where people do not question your technical desisions and just follow along. Non-ideal feedback is inevitable part of that.
4. Do you always give perfect feedback? Think about that next time you see a junior dev submitting a O(n^2) solution to O(log(n)) problem.
I’ve been a team lead and CTO, and when I was presented with some strategy or deliverable, it was my responsibility from that side of the table to speak from experience and point out banana skins and improvements.
There is really nothing personal at all in these interactions, it was just trying to deliver a better product as a team.
If you are putting forward bad work, or I am giving poor advice then the business has a performance management problem, but the to and fro of feedback is just a normal part of teamwork.
Thanks for saving your co-workers from a possibly tragic slip and fall.
One of the practices I've felt most helpful is to name the entity that is arguing in your mind and is telling you to take it personally. I named my voice Herman. I often tell him to shut up. It's a great way to distance yourself, albeit, it does sound a little mad.
Reminding myself that my goal is to be a better engineer tomorrow and not really to do a great job right now. I am after getting better, current work that i am doing is just way to get better. Taking such a position seems to solve lot of problems.
Criticism becomes something that i am actually after. I am not attached to what I build in the past. Of-course it is crap, i would not do it the same way now as i am better.
Take pride in getting better. Not in in the job done.
What is your responsibility is if you chose to listen or not - you don't have to be involved or give someone else your attention if you don't want.
I think software is creative and a sort of art so work is personal, but it’s collaborative and multiple people work on something. So even though I wrote it and they criticize, that means they are interested and wanting to improve the thing together.
That’s better than not caring or disinterest. Even if it’s their job and the are paid to make it better, it’s easier to build with feedback.
I subsequently learned to keep my perfectionism in check. As others here have said, honesty is the prerequisite to solving any problem, so please count your self-awareness in this area as a big win. Take your learning experiences in stride.
Personally, there's nothing you can tell me that is denigrating or unflattering about me that I don't already think about myself.
I am a short, fat, brown skinned, unattractive male immigrant of average intellect.
I already beat myself up quite a bit so it makes it very easy to accept criticism from others. It also keeps me constantly trying my best because I never feel like I'm secure in my standing that I can just relax. Keeps you humble too.
But at least I saved a ton of money on my insurance by switching to Geico.
That is confidence/self-forgiveness summed up in a mantra.
You have ideas floating around in your head about yourself and external "validation" of those ideas result in pain. When someone does something that results in you feeling pain, it's natural to feel defensive.
So it's a matter of shifting your focus from external (in)validation towards internal validation.
1) Professionals in your sphere: Take as much critics from professionals in your sphere as you can. Sometimes you need to even pay for this. Analyse and go forward. The more mistakes you will make the faster you will reach your goal. Act it as a game.
2) All others: Just tell them magic words: "This is only your opinion, Thanks!" and do nothing.
Be happy )))
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 :)
I have gotten honest, sane non-trivial constructive feedback/criticism of my work before, but I don't tend to remember it unless it was extraordinary - like someone went way out of their way to pump me up before burning me (my work) down with some accurate and correct criticism. I like managers and senior co-workers like that, good on them.
I don't necessarily remember the specifics of bad criticism, but I feel like bad criticism is bad because it is either designed to be taken personally, or is so careless that it is inevitable that it will be taken personally -- that is, it actually _is_ a personal attack, dressed up as work criticism.
I have vague recollections of various project managers and lead/senior engineers during various tenures that I have butted heads with due to their insecurities, incompetence, etc. There are petty people all over the place, esp in a 9 to 5 environment -- wage slavery can be a breeding ground for all sorts of bad behavior.
I do like working with smart, confident, nice people -- not an easy combination to find in a single person, much less an entire team/company.
That said, I like the whole 'mindfulness' approach to life, think it's worthwhile, don't necessarily see it as 'killing part of yourself' like i used to, more like a necessary evil in this very crazy world.
An old colleague shared a quote: "dysfunctional behaviors are functional in dysfunctional environments".
I've had to change up my style when I've moved to better (less political/dysfunctional) teams. I've also worked with some that never changed their mindset after being on a bad team: they then propagate that same broken behavior at their new workplace.
Best of luck in finding something better, it's out there.
As others have said, it's a senior dev thing, after awhile you realize you won't care by next week. There are some coworkers that are jerks, but they are usually in the extreme minority if you are working at an ok place.
In the lab we used to say "Well, at least no one died!", usually to defuse a situation that was bad. Like say, water from the ceiling leaking on to your half a million dollar laser...
You've got to learn to differentiate "you are acting like a child" and "someone somewhere is playing with you". Listen and trust your feelings. If you're feeling bad, 90% of the time it's your body warning you of some external danger.
Force yourself to trust yourself.
The simplest remedy is discovering your self-worth notwithstanding the comment. Remember your intrinsic value and the accumulated value you've already brought to bear.
Your ability to bring all criticism back into this context lets you treat it from a more detached (clinical) position. Judge the merit of the opinion, plan out any potential improvement or remedy, and frame your response accordingly...
So I just do the best I can which is apparently pretty good and just trudge on without caring.
Lots of discussions on where feedback might come from, what are the types of feedback (praise vs coaching vs evaluation), and how to incorporate (if needed)
I also want to echo the top comment here re:kudos on desire to improve
The company I'm at isn't really like that, but I've worked at enough that it's really, really hard not to think they will be. And so the instinctive reaction is to defend myself. I think I do pretty good at controlling it now, though.
If your company is not firing people for making too many mistakes it seems that it's structured in that way or a similar one.
Life is complicated. You are not omnipotent. These are very basic absolute truths.
You need to actively recognise this, and make it a part of your core mentality, and mentality drives the sentiment. Sentiments drive emotions. Emotions control how you react.
"The Four Agreements" https://amzn.eu/d/cB522Cj
and
"The Fifth Agreement: A Practical Guide to Self-Mastery" https://amzn.eu/d/3inVZsD
Unconstructive stuff that is almost meaningless and without content like "this is code smell" or "should refactor this" etc. is not, and I will not appreciate that kind of criticism.
> Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
Assume this attitude when you're looking at other people's work and questioning their decisions. Assume that others will do the same for your work.
Remove any kind of personal attack, analyze your actions and think about how you may improve to avoid making mistakes and getting negative feedbacks again.
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 does not always work, especially if I'm tired or distracted, but if I start catching that I'm getting annoyed, I try to take a break.
Take no offence if the company wants it done in a particular way as they’re paying for it.
Learned this lesson mostly from sports, fwiw.
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 don't know what to do, because I don't like burdening someone else, or failing myself to a point where someone has to give me feedback. Just a perfectionist attitude.
I try to categorize these bits of feedback by “is it at least partially true?” and “was it well-intended?” If it’s either of those things (most are both), I want to figure out what I can learn from it and realize that I’m the only possible person who will care about this feedback in 2 weeks’ time, so it’s up to me whether to care about it or ignore it.
How to know if you are not convinced of that? If it feels like you need courage to fix or redo something. Similarly, if you boast about your courage.
To me that's the difference between an A and B player, both are good but for B doing good work is somehow painful.
To answer your question, since nobody is omniscient, realize that if you feel bad for making an honest mistake you are fighting Nature.
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.
People above me on the org chart are usually coming from a broader picture and, at worst, in the back of my mind I can tell myself "this is just marching orders". For people below me on the org chart I usually have the mindset of I'm just an old fart and this is an opportunity to maybe learn something new or communicate better.
I have to really work to not end up in a confrontation when a peer criticizes my work. My usual mental reaction is "who the eff are you to say anything about anything!". How I cope is I wait 24hrs before responding, usually I'm way less emotional after some time. 9 times out of 10 the criticism is not something warranting a fight and i come away from the experience having learned something.
In my business peers are competition though so having such a hostile reaction to peer criticism may not be typical.
I view PRs as a kind of luxury. At many corps the deadline is yesterday and any single mistake you make ends up in production without reviewing or testing.
In the context of something like a PR, a comment that suggests something but you disagree with, you simply tell them that with a bit of supporting evidence. If you do agree with their suggestion then that's an awesome gift they've given you!
I think the core problem therein is specifically the word "pride". That is to say, a lack of humility. It is a raising of my own abilities above some set standard. It is to find some "special" value in my own actions and ability. It is a desire to be recognized for my work.
Humility then, is what I need. Humiliation is the means in which I learn humility - to be frustrated and upset with the response from others, but to not respond with those feelings and instead absorb the information as best I can.
To put it clearly: You don't stop being offended by criticism, but learn to process it more productive ways.
You learn to deal with people pointing out your shortcomings by examining the shortcomings that they point out. It then is a matter of realizing that those are shortcomings. After realization, with time, comes acceptance. After acceptance, (hopefully) a motivation to do better. This is a process that in my own experience takes years to accomplish. This isn't to say that, even if you were to do this you would somehow become the most humble person ever, but simply a slightly less prideful one. To work as hard as before, but a slightly softer head.
You will still have many areas you might be extremely touchy about - maybe even retreading old areas you thought you had overcome. (Been there!) I don't think that there is some "magic cure" to this kind of sensation. I simply think that you start to identify the process of dealing with it in a more constructive manner over time. Part of that requires learning more about yourself, and identifying patterns of behavior others bring up.
Arrogance (pride) is an absolutely huge part of my own life. Trying to tame that requires feeling a sense of humiliation on a routine basis. I don't think I'll ever become "numb" to it, but simply be able to process the repercussions more quickly than I had previously.
If someone is asking for changes, that implicitly means they're willing to review those changes as well. If it's good feedback just comply. Realize that if that person is holding you to a high standard, they're probably holding others to the same standard, so your life will be easier.
Changing your perspective can make it easier to take feedback non-personally in the future.
- Take a time to think about that criticism. Don't answer immediately.
- Realizing that someone make and effort to make constructive criticism shows common interest in the issue. Without it, nothing valuable is build.
I personally value more constructive criticism in my work than compliments. I'm not saying that compliments are useless, but the prevalence of compliments could make criticism personal.
Another nice example:
"I'm so sorry, but this looks stupid"
Vs.
"I'm so sorry, but you're being stupid"
As others have written: always assume best intentions first and try to read the comments in the most favorable way.
Here’s my story: Just over a year ago, I was working at a FAANG co and got head hunted by a recruiter for a promising growth stage startup. Everything was great, until they hired a non-technical director for engineering, and the founders handed the reins of engineering to this guy and mentally checked out from all things engineering. A few months later, he goes on to hire a pseudo technical slacker who cannot code without CoPilot/ChatGPT as my team lead(hard to believe, I know). I kept asking to switch teams, but it fell on deaf ears. Finally after getting a stellar 6 month performance review, my non-technical manager gave me a needs improvement rating for the 2nd year end perf. And this was in spite of being the most prolific engineer in the whole company, with ~20 engineers. It turns out that my manager always wanted me out, and had been building a fictional narrative behind my back, out of my requests to switch teams for months. Needless to say, I wanted to leave at that very instant, but resigned served the notice period and left soon thereafter.
Now, I’m working on my own startup for over a month now. I’m working super hard and I haven’t been this happy in a long time. Life IMO, is too short to put up with toxic BS like what my manager put me through.
Being able to absorb criticism without personalizing it is a skill that needs to be learned and practiced. And you will not always get it right even when you get pretty good at it.
This individual explains how their process of sharing feelings on something is often perceived as an accusation by others.
There are always at least trade-offs made between conflicting quality goals. Understand that others will value trade-offs differently. In a team, their preferences count as much as yours.
You wrote the code, but it is not you. Critique of the code is not critique of you.
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.
I used to get a lot of negative feedback from my boss, every week it was something else. Turns out he was going through a bad period. I switched bosses and everything was fine. It sucks when it's your boss, but it's still only a personal opinion of one person.
In sums ways you’d hope todays work wasn’t don’t improving or you would end up having pages.
Criticism is that if it’s not improved upon.
The operation who gets to learn, grow and improve is the winter compared to the person pointing it out.
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.
Nothing sucks more than working alone several weeks on a PR and then getting reviews about the whole approach being wrong. This applies to both for the reviewer and the recipient.
Better work in tandem together with someone and share the ownership of the design.
Take it as a gift. If someone didn't care about you and your work you would never hear a word.
In order not to get upset or bogged down by feedback i start with saying: thank you. Then I try to remind myself of how careful I try to be when providing feedback to others and/or how hard it can be at times.
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
Just because you made it doesn't mean it is great, applies to code, things and kids equally.
And vice versa just because someone didn't like it doesn't mean it is bad or have problems. But if most people did, well, maybe it does.
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
The good news is that pain is what's going to help you learn, we form memories better when we experience an emotion than when we feel detached.
You'll feel good about it the next time when you get to apply the learning!
As the point we're you are allowed to get good feedback.
Next time press the button for opening a PR and think 'ha I'm curious what I learn today!'
Don't open a PR and assume you will be merging it soon, open it to be able to work on your fine-tune process
There is a difference of valid criticism and cynicism though. The people who criticize because they want you to do better are those to keep open ears for. Those who are just cynics can be largely ignored.
It's worse with neurodivergence in the equation. It gets easier. A therapist can help.
1. I am not my job.
2. I, like my coworkers, like most moderns, have Bullshit Jobs, and I don't fool myself otherwise.
By these tenets, it becomes very difficult to take personally something that you do not personally identify with.
I'm very careful to be constructive and refrain from being offensive in my tone during code reviews. I do this to my coworkers, and some of reflect this back at me, which means that it is possible but not everyone does it.
Do you get upset when you’re playing soccer and a teammate calls out for a pass? Or when you’re playing a video game and a teammate calls out an enemy approaching you from your blind spot?
If you're not getting constructive criticism, it's probably time to move on or improve hiring in your team.
Of course I'll be wrong. But its best to learn where I'm wrong so I'll be aware for next time. Learning why I'm wrong is the take away, not that I was bad.
If the only significant thing in your life is your job, then your identity will be inextricably tied to your work. So criticism of your work will be an attack on your identity.
Become a well rounded person and your ego will naturally shift its locus.
People "criticizing" might be wrong or right, but it points me to reflect and understand my choices. If I'm wrong I learned something, if I'm right I can test my skills to argument cleanly.
Embracing this “forever noob” mindset has been great for learning
I can keep moving forward on my own, but criticism helps me go in the right direction.
I want constructive criticism. I want it raw and direct. I want it from a friend who can hear my own criticism of them.
I'm always learning how to do it better.
After that, it's easy to graduate to the next level: _memento mori_.
Perspective heals many wounds.
The tools there are astonishingly effective at reframing one's relationship with criticism (reasonable or otherwise). Highly recommend.
Someone took the trouble and spent (maybe) even a little time to comment. Maybe you should be thankful of that.
Glass could be half full or half empty, depending on your perspective.
it is not you! i think most of the people feel the same way. at least i do
i suspect that in your case a review is mandatory as well as fixing its comments.
from my perspective a review should be optional. You should ask for a review if needed and ask whomever you consider worth making it. You should be responsible for your code and have authority to change it without any PRs.
You also learn that you are usually not the smartest person in the room, nor the dumbest.
I find it helps to imagine a scene from a mafia film where a hit man tells his victim that it isn't personal and "just business".
Add humor wherever possible.
Speaking for myself: I wouldn't desire to be disinterested in my work.
The best way is to take a break, this makes it easier to evaluate the information in it's proper context.
Seriously. Once I completely quit over 6 months ago, I am much better at "water off a duck's back" in many areas of my life, including this one.
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.
1. i am human 2. humans are all fallible 3. we all make mistakes 4. i am not my work
I also fully believe that every time someone points out something i've misunderstood, or a way I could have done things "better" it's a gift that teaches me how to get better at what i do. "Stupid" mistakes like, typos or forgetting to do something you know all about are just part of being a falliable human.
If it's not, they're being an ass and their input is worthless.
People who criticize people vs critique code are wrong.
This applies also more generally in life: you are not you mistakes/ past / action / thoughts.
To grow seek people whom you really think know stuff.
Best piece of inspo: have a goldfish memory when it comes to criticism and failure
That is, forget after 3 seconds
Process, not people. That concept has been a central driver of the culture I carry forward. If things are going wrong it is infinitely more productive to assume people want to succeed, but the process we have has prevented the outcome we want somehow. Even if sn individual made a mistake it is still possible to point to training, procedure, or even culture as being the real issue. This doesn't apply in cases of ignoring process or intentional incompetence, but that was very rare.
When people criticize me I am quick to try and focus on what could have been different about the process to lead to a better outcome or how I could have better managed expectations to reduce confusion. Of course I am in product management so managing expectations is what I do. So often disappointment and frustration come from a place of confusion. The more transparency someone has into why things happened the better they usually feel about the outcome.
TL;DR Focus not on yourself but the process that lead to the outcome. Mistakes are inevitable. Bad outcomes from mistakes only happen in poorly designed systems and processes.
seeking your own counsel may prove more useful than seeking the counsel of others.
maybe someone will say something helpful, maybe not, in either case it might give you some ideas.
It goes like this: When you notice that you’re receiving criticism, pay attention to your emotions. You’re looking for defensiveness, anger, etc. When you notice that feeling, briefly imagine a future situation in which the person who made the criticism actually implemented those changes; it can be helpful to make it slightly absurd (the example I usually use is their criticism is about my long-hair hairstyle, and I imagine they forcefully cut my hair into a different hairstyle - for your case, maybe imagine they edited your code and approved the edited version without asking you).
Now try to imagine a hypothetical future situation occurring where that change saved your ass (for my hair example I offer ‘a date goes really well, and then she offhandedly mentions how much she hates long hair on guys’ - for your case, maybe imagine your company picks up a big contract with a new client and their use case would have crashed production with your code but it holds up with the changed code). Focus on the relief you feel that the forced change ended up saving your ass. (If you have the introspection skill, try to consciously transfer that relief away from “absurd forced change” and associate it instead with merely hearing the criticism - but if that mental operation doesn’t make sense to you, don’t worry, as long as you feel that palpable relief, the technique is working.)
People have described this to me as janky and “a weird hack that shouldn’t work”, and I agree it has that feeling to it, but it’s also worked incredibly well for me and many people I’ve told it to. Over time and with practice it becomes a more fluid mental operation: eventually when you get criticism, a way in which this critique saves you some future pain will jump into your head spontaneously. Early on this will only be applicable to asynchronous situations like internet comments; as it becomes more automatic you will be able to apply it in real-time conversation too.
Try it out! The best metaphor for why it works that I’ve ever heard came from someone who took me aside a week after one such lecture and told me she’d been applying it. She said that it feels like criticism starts an “anger”-fire in her head and this technique is like imagining a firehose into existence so she can spray “relief”-water onto the blaze - essentially, that it’s a way of generating a counter-acting emotion to fight the existing emotion with.
Obviously, only use this when you want to accept the criticism gratefully. Some criticism is mean-spirited and not useful; less than you are tempted to think, but non-zero.
if you can somehow find a way to make it fun and enjoy the process (knowing you’ll get a better result, quicker) then you’ll know you’ve won!
Then, if you are an employee, it helps to think that you already have been paid for the work being criticized. Sounds unrelated to the original problem, but for me it helps to dismiss a potential source of stress. Also related to the fact that you are not your work and it is not good to identify with it.
Also, think of the times when you might have come out as too abrasive to a colleague. Think how you would like you comments not to have been taken so harshly. Do the same with other's comments.
Long version: Plenty of good advice here, but I wanted to add something that helped me in this regard. I grew up in a household where everything was criticized for any and all reasons, most of which could be boiled down to "I feel bad and in order to make myself feel better, I'm going to do something that makes you feel worse than me." Being born into that kind of atmosphere makes it very difficult to understand that a) it's not normal, and b) criticism (when used appropriately) isn't about making a person feel bad, it's about trying to improve something. It was just never used appropriately in my household growing up.
So many (way too many) years later, I started getting into the skeptical movement. What initially attracted me was that it was about tearing apart stupid ideas (so pretty similar to what I grew up in). Someone would claim to have a photograph of Sasquatch or a UFO, and people would show how the photo wasn't what it claimed. But it was a lot deeper than that. There were doctors debunking bogus medical cures, and people pointing out that businesses were scams, etc.
That was all well and good, but as I read more and more about how to get better at spotting these sorts of things I read a lot about cognitive biases and logical fallacies. Something soaked in because I found as I understood my own thinking better, I had a better understanding of what could and likely couldn't be other people's motivations for saying the things they said. Whereas before I might think, "Oh that person's just saying x because they dislike me," or "because they're jealous that I have y," or whatever, these days I'm better at saying, "Well, they might just be saying that because they don't like me, or it could be they don't have the same experience as me, and don't understand my motivation for why I think like this. I can try explaining my motivation and see if they understand or not. And maybe they'll understand or maybe they'll explain something to me to help me understand their point of view." (It's more complicated than that, but it's hard to explain in a comment.) Anyway, a lot of the pain of getting criticized evaporated when I could reason better about other people's motivations.
Instead, do something about it. Don't react right away. Identify why you failed, what could be done next time, and then try not to make the same mistake again. Thank your colleagues for pointing it out, and move forward.
But take it as an opportunity to become better. Nobody became good at first try.
Your work is not who you are.
Your work is not who you are.
Really internalizing that is step one.
You are smart enough.
This one is a lot more subtle but worth a ton if you can internalize the implications of it. The fact is others are smarter than you, some aren't as smart as you, and the truth is you really shouldn't care.
What you do need to realize is that for all of us it boils down to the amount of work we need to do in order to accomplish something. And everyone varies widely in this.
Here is a thought experiment for you: say you take a person of below average intelligence, but they are raised among Geniuses basically. And these geniuses, being the chairing smart people that they are, never really let on that the person of below average intelligence is below average.
Now take that same scenario only this time the person is around not so good people they're not so smart they're not so caring.
Secret to getting your ego out of all of this is to compare and contrast those two scenarios and what they're going to mean mental health confidence of the person in question.
In the former scenario, that below average person is going to learn a ton of smart ways to do things. And they'll be confident in the doing them. Others may not even know how smart or lack of smart they are.
In the latter scenario the person is acutely aware of their deficiencies, and there's a whole bunch of negativity that comes with that, along with a lot of work because they didn't get to learn a lot of smart ways to do things and so they struggle. And they're not confident.
Rather than value your work as some reflection of your identity and how smart you are or some other attribute that you value it could be anything. Rather than do that, value outcomes and other people.
A very large part of who we are depends on who we hang with, and how we handle that.
I used to play it much differently, like some kind of competition, and criticism of my work had a high impact.
Today I seek people that are better than me in areas that I need to improve, and I share what I'm good at with others who want to improve.
And the outcome is we're getting shit done, it's done right, and we feel good about that which is done.
Let's take something simple like a presentation, or a chunk of code that has to perform a task.
What is more important?
Is it that your contributions are the very best?
Or, is the most important thing that that presentation or volume code nailed the task at hand?
Answering in the latter case allows you to take criticism of your work because it's all intended to achieve more important goal. The more we achieve those important goals more successful we are as people, teams, companies.
Here's one last thing comma and it's simple it's a phrase comma but it really helped me:
"Nice catch"
I was working with someone once was on a standard body and they have to do lots of detailed work and it gets revised many times and it has to be right it's right as people can get.
They used that phrase all the time when inconsistencies errors improvements were found.
And it took me a while, but I realized what that phrase meant. And it's about being one of a body of Skeptics being skeptical together to make it better whatever it is.
So give to get benefit of the doubt, give yourself a personal out so you don't have to take it personally and worry over every little thing or criticism that you may see.
Instead, think or say nice catch!
That really helped me make a big mental shift and a ton of things are so much easier today with you worries. Good luck and take care.
Meta: I use the Google voice input on this one, and hope to catch it in my edit window, until then please forgive typos and cats.
That said, it of course can feel unpleasant! And if it interferes with how you function in the workplace, perhaps it’s not useful to you. So for instance, if it causes to lash out at your coworkers for their feedback, then it would be important for your relationship with them to not do that. But based on your description it already sounds like you aren’t doing that, so it sounds like mostly an issue that’s internal to you, right?
If that’s the case, and really the main concern is for your emotional and mental well being, then there are kind of two different dimensions on which to address this.
First, as I said before, if you receive criticism and take it personally (whatever that might mean for you - sadness, anger, various thoughts arising), the way you’re feeling at that moment is exactly how you’re feeling at that moment and it is a completely natural phenomenon. You can’t undo how you’re feeling, or go back and react differently. So if you can see your feelings as naturally occurring and not indicative of some fundamental flaw, over time, even if these “taking it personally” reactions occur, they won’t bother you quite so much. This is the dimension I might refer to as “how you relate to the content of your experience”. IMO this is the more important dimension because it’s really in our control and is universal to all aspects of our experience!
Second, there might be ways to consider and address what’s causing you to react the way you’re reacting, but that’s a bit harder without being able to ask some more questions about what you specifically mean by “taking it personally”. Is it anger? Sadness? Guilt? Is it fear that people will think you’re bad at your job? Do you feel bad yourself for having made a “mistake”? Investigating what specific assumptions are going into this (maybe with the help of a therapist or some other trusted party) might help uncover what’s leading you to feel bad when receiving criticism, and then perhaps address that directly. This is the dimension I might refer to as “addressing the content of experience”.
Without talking to you more I can’t help much with this second dimension, but I can say a few generic things to take a stab at it:
One thing I might point out is that you used the word mistake several times - so it sounds like you think there was a right way and a wrong way for you to have done the task, and you did it the wrong way, and that’s a Bad Thing, and these comments are pointing that out, and maybe you’re afraid that means YOU are bad (or that others think that). In reality, while yes, the first code you put up might have had a bug, that is not some kind of absolute failure on your part. The whole reason code review exists in the first place is people will always be writing bugs and bad comments! It’s a learning experience. Substantive patches are rarely approved the first time without comments. (You did even said they were “honest mistakes”, so it seems like you know it’s natural for them to occur - so maybe my comments here are off base with what you’re dealing with.)
On the other hand if you feel like other people don’t know it was an honest mistake, and you’re worried about how they perceive you, the thing that helped me with that concern was realizing that I’m exactly as good at my job as I am, and no matter how much I try to control the way I’m perceived, over time people will recognize if I’m bad at my job or will recognize I’m good at my job, and that’s just how it is.* So all I can do is try to do a good job and learn from my experience, and other’s perceptions of me will play out accordingly.
Again I don’t know if these last two parts help or address your particular concern without talking to you more but am including it just in case.
Also just in case, I want to say it’s possible that the team you’re on is not following best practices for code reviews and that their criticism is coming off as overly harsh for that reason. So it might also be worth looking online for some code review guidelines to see if people are acting accordingly or if they’re saying things like “Lol I can’t believe you forgot a semicolon here, jeez, what are you, a noob?” (Being silly on purpose here but there are more subtle versions of this that can make people feel not so great.) Even if that’s true all of the above still applies I think, but it might be good to know or address if people are commenting in inconsiderate or mean spirited ways.
Anyway best of luck!
* ignoring cases here of people who are somehow extremely manipulative to hide their incompetence, which I’ve fortunately never witnessed, and I assume most people don’t want to be like that anyway so I’m not addressing that
I have made (and continue to make) many mistakes. Some, are used as leverage by others, to attack me. Most, I find them, myself, and feel like a jackass, but the problem gets fixed (sometimes, in both cases, but always, in the second case), and the lesson gets learned (in both cases).
I'm generally my own harshest critic. I expect a lot from myself, and don't cut myself much slack.
I've come to learn that having a critical and unvarnished self-awareness, takes the teeth out of whatever anyone else thinks of me.
Call it a "fearless and searching self-inventory." I know myself, quite well. There's a bunch of stuff that I'm really good at -way above average-, but there's ten times as much stuff I'm not good at -some, embarrassingly bad. I need to have a clear and unbiased awareness of this.
I don't hide what I'm good at -and that often ends up with people calling me "arrogant," but I also don't claim expertise in stuff I'm not good at, I welcome valid criticism, and self-correct, when necessary.
I now believe and do stuff that, once upon a time, I scoffed at.
"Good judgment comes from experience. Experience comes from bad judgment."
When it comes to criticism of my work, it's often context-sensitive. For example, thread-studly code can look quite primitive, because we aren't doing fancy stuff in a long line, but doing simple stuff in small chunks, and being careful where we get it, and where we put it, or we don't DRY, because we don't want to break cache or pipelines. We may also write code that is designed to be maintained by less-skilled engineers, so claims of "overengineering" may have merit, whereas, if we are writing code that we, or a skilled engineer, will maintain, then getting fancy is fine.
Much criticism actually comes from personal insecurity. We may feel bad, but the person delivering the criticism may feel worse. If I'm on a team with them, then it might be a good idea for me to be empathetic, polite and forgiving, as opposed to telling them to go piss up a rope, or sawing on my wrist with a butterknife over it. Maybe simply explaining why we are doing things the way we are, could actually teach them, or reacting politely, when they are deliberately trying to goad us, may help teach them to be better team members.
The lessons aren't always technical, and they can go both ways.
Also, I am often wrong, and become right, by admitting that -even if it is humbling and embarrassing. Just because someone else is delivering their criticism like a jerk, doesn't mean they are wrong.
Once I started to see my work as a 'game' played by a 'role', a lot of stress was taken off of my back. I started to see situations in a neutral light regardless of who were the actors (including myself).
It doesn't matter if it's me receiving or giving constructive feedback, having a difficult conversation or managing a stressful situation. Through this perspective I'm able to abstract from people, power dynamics, etc. and see what's helpful, that's the best way forward, etc.
At first this approach only existed in my mind. I didn't dare to externalize it because I was wary people might see it as odd or disrespectful. As I fully implemented this philosophy in life and at work, I dared to socialize it with good results.
For example, instead of saying "John's performance was poor" I would say "this role's mission is to add value to XYZ, I think we can do better in that area. What support do we need to achieve better results?". And people react really well to that way of framing things. This language adaptation can work well in OP's case. Maybe the manager said "you sucked when doing XYZ because you missed an important thing". You can translate that as... "I don't suck at anything and that's a bad way of framing things. But in the future when my role is in a similar situation, I should do XYZ to have the right insight to do my job". Another tool to manage feedback is to imagine it's not about you but about someone else. Imagine is a friend telling another friend about a situation at work. Would you still think "there's no way person X could have known about that"? If so, a good answer in a PR is... 'if the same situation happened tomorrow, how could I get better insight, or know who to talk to, to achieve better results'?
Something to highlight here is that there's always two sides of a coin: it's great that you want to learn to take constructive feedback as a growth opportunity and not as a personal attack. But maybe if your gut feel gets constantly irritated is because you have found a genuine case of toxic work environment. "Snarky comments in a PR" raises a red flag to me. To be professional means to treat others with dignity. If that's not happening is time to consider jumping ships.
So, OP: well done in keeping yourself in check. It's hard to take constructive feedback well, but it can be done with tools like the above and others. While doing so, make sure you're not surrounded by toxic colleagues and leaders and when that's the case, run fast and far and don't look back.