Today Nolan Frausto writes today about what he calls the "code culture problem:" one colleague pronounced another's code as "shit" and then drags a third colleague into the first's whirlpool of negativity. This doesn't have to be and the answer isn't just to write perfect code all the time.
First, this kind of behavior can't be tolerated. Not one bit. This kind of negativity is, obviously, counter productive for the person emitting it. The bigger problem is that it's contagious and corrosive as demonstrated in the blog post. I'm strongly in favor of teammates having a vigorous disagreement, but it always needs to be based on respect and everyone needs to finish with cool heads. I consider this a big management/culture problem.
Second, to quote Nolan "What does that even mean?" The flavor of this I often hear is that one developer considers another's code to be "messy." I hate this word (and semi-jokingly forbid its usage on my team) because it's lazy, ambiguous and ultimately doesn't mean anything.
Code can have all sorts of problems: it can lack tests, it can have classes with too many responsibilities, it can have overly long methods, it can have duplicated statements, it can have ill-conceived abstractions ... but unless it's got inconsistent indentation, I don't think any of that is "messy." When people use flimsy criticisms like "messy," especially as justification to rewrite that code, you need to challenge that person to provide an argument with substance.