My suggestion is to do more design work up front before touching code. Write up a plan in a drive document or an internal wiki tool, with a focus on capturing requirements, a high level description of your proposed solution, and detailed sections on the portions you anticipate to be complicated, controversial, or risky. Also include an "alternatives" section where you very briefly summarize technical approaches that you considered but ruled out.
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".
Respectfully, I don't think this addresses the author's question. They asked for help receiving criticism. Your response is focused on better engineering practices, with the goal of reducing mistakes. I don't think that is what they are asking for
I think you missed my point then. The goal isn't to reduce mistakes, although that is often a secondary benefit. My suggestion was to shift work habits to a form where they have ownership of design rather than ownership of code. Also, a key point was to front-load criticism to early in the development process rather than toward the end.
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.
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".