There is a commonly expressed idea (a recent example here) that can be summed up as “you are not your code”. In short, if someone tells you “this is bad code”, you should rejoice, because it’s an opportunity for improvement.
When expressed, everyone rushes to agree with this sentiment. And so do I. It is very difficult to improve if you cannot listen to criticism and make changes based on it.
But there is a another side to this that is rarely expressed. When someone delivers this message, you are actually the person who wrote the code. You are not the code, but you are a person who wrote bad code.
When you receive this message, it should be not only a time for rejoicing in the learning opportunity, it should also be a red flag. You do not want to continue to be the person who writes bad code.
Consider the situation where this message is delivered in a code review session. The team is gathered, the code you wrote is being projected on the wall, and, well, it’s baaaaad. People are snickering behind their hands or WTF-ing all over the place. How many times do you want to hear “this is bad code”? Put another way, how many times would it take before you would begin to be labeled as “the guy who writes bad code”?
No team wants that guy as a member for long, whether learning is taking place or not. It’s a drag on everyone else’s attitude and on the team’s output – someone is going to have to write the good code to replace the mess you wrote (or take the time to supervise your rewrite).
So, go ahead and use constructive criticism to improve. But don’t let yourself be in a position where you keep receiving such criticism.
You’ve got to learn, and not just from code reviews. Take the initiative to get out of this penalty box. Take some time to study the code of team members who don’t get criticized, because they write good code the first time. Read a book, subscribe to some RSS feeds on coding, do some code katas. Refactor, using some better or clearer techniques from the language.