It's not a well-worded sentence, but what he means is that if you have to call out an ugly hack, the REST of the code is probably pretty decent. If the code is full of ugly hacks, they wouldn't be worth mentioning.
I think an important point is that the programmer recognized that what he/she was doing was an ugly hack, (presumably under some serious constraint, like time) and felt compelled to point this out.
A mediocre programmer might come up with the same fix, but not recognize that the fix was an ugly hack, and not comment as such.
I agree with the OP that this is a positive sign. The only thing that surprises me it that it seems to be a free-format arrangement of a word that can be used in a positive way. We have a magic comment word ("kludge", if you must know) that we use for code that we wish we had time to write better; that in principle allows us to go back and find things to fix after the fact, or helps troubleshooting since kludges are more likely to break.
I'm not terribly creative with code I write for others. Since I've been doing a lot of Java recently, using Eclipse, I stick with
// TODO:
Which has the added benefit (in Eclipse) of creating a tiny blue box in the vertical source error/warning/status bar (I'm not sure what it's official name is) so I have a visual cue to see where I have unfinished business (Kludges are unfinished business that you might get to next day or never, but even if it's a glorious hack, if you think its a hack and not a "proper" way to do it, its still unfinished business. In a prior project we used to use "glorious hack" as a special comment to use as the first places to investigate when something broke.
I agree with his assessment. Sometimes ugly terrible hacks are the best solution given the external constraints (time, 3rd party code beyond your control, whatever). And if you have an ugly terrible hack, you should definitely comment it.
Yes, but then you should go back and fix it. One can only hope that there were more "ugly hacks" that have since been fixed.
The measure of a good programmer is not whether he or she recognizes when they're writing bad code, but whether the final result is free of bad code, and thus more maintainable.
I would argue that someone commenting known bad code, but leaving it there in perpetuity is no better than someone unknowingly writing bad code (although the comments could serve as signposts to help someone else find and fix your bad code - but how often has that ever actually happened?).
I don't agree. I think all code of any size, bad or good, has these words in it. The problem with his statement is that "UGLY TERRIBLE HACK" is relative. One man's terrible hack is another man's normal day-to-day style. In bad code, there are just more ugly hacks that aren't commented as such.
For Microsoft or for everyone?