My experience with feedback comes in the context of software engineering. Any competent software engineering team requires code reviews for anything going into their product - whether completely new code or trivial modifications. One or more software engineers other than the code author look over the code, pointing out any issues of potential issues they see. These can range from trivial typos to major security risks, from outright bugs to ways to make the code just a wee bit less failure prone. I believe just about any other engineering discipline has similar practices.
It's not much fun receiving this kind of feedback, particularly at first when you probably don't know all the tricks of the trade. You figure "my code works - it passed all my tests - why are they badgering me to make stylistic changes?" You come up with excuses for why the problem some pedantic reviewer noticed doesn't matter . And you feel miserable and somewhat scared while waiting for feedback. But you are highly motivated to control this reaction, lest your colleagues look down on you.
I nonetheless came eventually to love this feedback, seek out the best and most thorough reviewers, and put considerable effort into improving my own reviewing skills. It's so much cheaper to fix a problem before it's been shipped to customers. and while it may be embarrassing to have a senior colleague point out a mistake you made, it's much less embarrassing than being the idiot that brought down half the airlines in North America (Hello, Crowdstrike ;-() or half the phone switches manufactured by AT&T. Or ....
As a side effect of learning and using this process, I'm perhaps a wee bit more willing to accept negative feedback outside my professional life. And sometimes that sort of feedback is by far the most important.
My experience with feedback comes in the context of software engineering. Any competent software engineering team requires code reviews for anything going into their product - whether completely new code or trivial modifications. One or more software engineers other than the code author look over the code, pointing out any issues of potential issues they see. These can range from trivial typos to major security risks, from outright bugs to ways to make the code just a wee bit less failure prone. I believe just about any other engineering discipline has similar practices.
It's not much fun receiving this kind of feedback, particularly at first when you probably don't know all the tricks of the trade. You figure "my code works - it passed all my tests - why are they badgering me to make stylistic changes?" You come up with excuses for why the problem some pedantic reviewer noticed doesn't matter . And you feel miserable and somewhat scared while waiting for feedback. But you are highly motivated to control this reaction, lest your colleagues look down on you.
I nonetheless came eventually to love this feedback, seek out the best and most thorough reviewers, and put considerable effort into improving my own reviewing skills. It's so much cheaper to fix a problem before it's been shipped to customers. and while it may be embarrassing to have a senior colleague point out a mistake you made, it's much less embarrassing than being the idiot that brought down half the airlines in North America (Hello, Crowdstrike ;-() or half the phone switches manufactured by AT&T. Or ....
As a side effect of learning and using this process, I'm perhaps a wee bit more willing to accept negative feedback outside my professional life. And sometimes that sort of feedback is by far the most important.
Great observation! It sounds very similar to the experience of being edited.