I once had to advise someone who found himself irritated at receiving lots of comments during code review. I think my response was good enough to quote verbatim:
Remember: You are not your code. You are not the hundred or so lines of C or Java or JavaScript or whatever that you wrote today.
This problem arises because you are too attached to your code. Your ego is associated with the code you write and you feel that any comments or defects found reflect upon you as a person.
You are not perfect. You will not write perfect software, and that's fine. It's not a flaw, it's just the way software is. It isn't written all in one go, magically perfect and elegant and satisfying all the requirements. Good software goes through multiple iterations and many eyes looking at it.
It is also important to treat it as a learning experience -- learn what you can from each code review comment and try to apply what you learn to future code you write. This also helps you minimize review comments in the future. Instead of treating the large number of comments as a shortcoming on your part, treat it as a metric you can improve upon.
It's probably true of any endeavor which results in creation -- be it programming, arts, crafts or whatnot -- that you need to be able to divorce yourself from your work so that you can accept and analyze and learn from criticisms objectively and without feeling terrible about yourself.
Fun fact: All programmers write terrible code. Yes, even the veterans, the rock stars, the elite, they have all written terrible code at some point in their careers and they will probably write more terrible code in the future. The key is to recognize those instances -- either through introspection or being open to criticism -- and learning from them and trying to minimize them in the future. Or at least correct them earlier!
See Also
This is very true. It also gets more difficult to write “correct”’ code as you get older and gain more experience. The definition of “correct” is refined with experience and it becomes easy to get locked in analysis paralysis because you are much harder on yourself when reviewing your own code.
There is something to just sitting down and making something work as a newbie. The fact that something works provides motivation to continue… So much so that this has become my new approach to mentoring junior developers. Think about the problem, refine the high level design with input from others, and then code something that works. It’s easier to refactor a working system than it is to try to design the perfect implementation up front.