Amen, brother. As Martin Fowler writes, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."

If Mr. not-Einstein had actually measured some production issue that could be traced back to commenting, he could always have written a filter that stripped them before production. My guess, though, is even he didn't believe this excuse; it was just a glib thing to say in hopes of wiggling out of trouble for being a negligent coder.

That's the thing: if he'd said "I was cranking this code out quickly, but, yes, it could do with some comments", I'd have been fine with that. The excuse is worse than what he's trying to excuse!

Agreed! If somebody is going to bullshit me in an interview to cover up their weaknesses, I have to assume they're going to do it after I hire them.

Since you bring up Fowler, in his book Refactoring he gives specific examples to show why you should AVOID comments. In most situations you should try to write code that is so clear no comments are needed. That's what the above code is really about.

This! Far too often I see worthless comments because people were taught in school "you should comment your code".

I suppose someone could incorporate a procedure which strips down unnecessary strings from code files ("minifies"), especially comment blocks, during the deployment process, thus maintaining a nice development codebase while not having questions over performance.

Comments like: // Adds two numbers

// method takes Object argument and returns list

Are useless.