This has nothing to do with code, really - in any profession, people get emotionally attached to their work, and are unable to have a discussion without making it personal. What he means is that you should be able to discuss your technical decisions (code and otherwise) without feeling personally criticized/defensive.

Basically, you should be able to take constructive criticism and not defend your work based on anything other than objective correctness. You shouldn't get upset with someone who says "your code sucks," you should ask them "why?"

This seems like a good trait to have, no matter what job you're doing. Whether you're a manager, a construction worker, or a software developer, criticism should be seen as a chance for learning and improving, not a personal affront to your pride. But, I can definitely see that this quality may be especially important in software development because code reviews and design reviews are so commonplace and frequent.

Nobody else has even once reviewed my code. So I just assume it all sucks.

That makes two of us.

I wish it were more commonplace. I've been in the industry for ten years, and my current employer of two years has been the only shop where there are scheduled code reviews. I think it's great, and I enjoy reviewing other people's code as well.

That's one of things I like about my job. Every line of code has to be reviewed by another developer.

It can't be checked into source control until it's been reviewed.

There are lots of benefits:

We all have to write readable code.

We can't just put in hacks.

You learn stuff. When reviewing others code you can ask why they did something in a certain way. Sometimes you'll learn about the benefit of coding in a certain way, or using a certain method / style / whatever.

This also has the benefit of redundancy. It means at least two developers know an area of the codebase. So if they're away there are no bottle necks, the other developer can also code that area.

My thoughts exactly.

Maybe he meant you should always be willing to replace your code, either with your new code or someone else's.

In other places I have worked, this is referred to as "having thick skin". Essentially, you need to be able to accept criticism of your code when it is valid and be willing and ready to change it.