It's tough enough to have people criticize your code, especially when the comments are coming from an intern. On Slashdot, one anonymous user had precisely that gripe. After ten years as a developer, the kid "started ripping into my on how terrible it is," with complaints that are "simply because he does not have the experience with it to actually understand what the code is doing." His bottom line question:

He is a smart guy with lots of promise, he is asking good questions, but how do I get him to look past his own self perceived greatness enough to slow down and learn what we are doing and how we have pulled it off?

Slashdot being Slashdot, there was no shortage of suggestions. Of course, there was the tongue in cheek, like: Hire a second, unpaid intern to do the first intern's work, then have the first intern "do nothing but beautify your existing code, with the understanding that he can't change how any of it is written." Most people, though, suggested that the OP turn the situation into a teachable moment. The user Anonymous Coward suggested presenting the critic with some of his own code,  without identifying the source, and have him critique it. "After they rip into it and query why the code was written that way, reply: 'You tell me, this is your stuff from a couple years ago.' " Another thought some perspective might be in order. "Junior guys often say things like 'this code is crap,' not because they really want to change it, but because they want you to notice that they're smart," observed Dintech. "Instead, give the intern greenfield work -- plenty of room to prove himself without setting you off." PolygamousRanchKid said having the intern read The Psychology of Computer Programming would expose him to the idea of ego-less programming. Crazyjj took the hard-nosed approach: "Tell him to write the log-in page himself - after all, he's fresh from a CS program where they taught him everything." One of the more interesting bits of advice was to tell the intern to "Define Bad." It came from Sir Garlon, who wrote, "As an engineer, I've adopted the maxim that there is no good and bad, only fitness for a particular purpose. I prefer a discussion of trade-offs to statements of principle. I tend to ask 'what requirements does this code fail to meet?' And very often, the reviewer has invented his own new requirement." "Depending on your process, your response might be anything from 'good point, let's add a test case for that,' to, 'you should submit a Requirements Change Form for that," he said. But what about critics who hammer your code for things that are hard to quantify, like "readability" or "maintainability?" Sir Garlon has thoughts about that, too. Make the critic justify the cost of fixing the code to the boss. That would be a conversation worth listening in on.