I don't think your suggestion is a bad one, but I'm not convinced it would have a meaningful impact on one's ability to accept the criticism in the first place. Just because it is occurring at a different phase in the process wouldn't (for me) change my reaction to receiving criticism. But fair point that in your experience this is a useful strategy to make criticism easier to receive.
It's fairly concrete advice I've given dozens of times to more junior software engineers over the years. People have a tendency to become emotionally invested in the code they write. A large part of that tendency seems to be due to a sunk cost fallacy. When you spend the majority of your time iterating on code in order to work through unanticipated complexity and system level interactions, the code is perceived to be the value of your work. People ultimately derive happiness from feeling useful, and so it hurts to be told that the thing you labored over is flawed in some way.
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.
