First, you need to be able to critically evaluate the criticism.
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.
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.