In art school, we spent a lot of time learning how to give and receive critiques, because the fastest way to improve was to try frequently and critique often.
You learn very early to divorce your ego and sense of self from your artworks and embrace every attempt as an opportunity to improve towards an ideal you can never reach.
You also learn how to give meaningful criticism without being an asshole.
Writing code is very much the same.
Unfortunately, most software engineers haven't been to art school and have no formal training in how to give and receive useful feedback.
I recommend reading Art & Fear: Observations On the Perils (and Rewards) of Artmaking. It's a good book that helps you build a healthy mindset towards growing as a creative:
I also got my first critiques when getting a degree in Art. One of the most memorable lessons and discussions was when I first was taught that once you put your work out there, it is no longer about you. Not at all.
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.
Most normal education tends to skew towards the didactic all the way through your undergraduate studies, especially with the math and hard sciences (which includes most CS students).
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.
You simply have to do it every day with self-awareness of what you're doing and why it's important until you get comfortable with it.
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.
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...