The "//just pseudocode of course" meant that that wasn't actually how you'd do it. Instead, you'd come up with an overall better design in how you handle resizing pages. If anything this proves the point that self-documenting code forces you to re-think your design often when something is fishy to begin with. In this case, setting "$.resize.delay = 16;" probably is an effect of deeper design issues. Not being able to fix it by just moving it into a function simply means that striving for self-documenting code forces you to fix the issues rather than patch them with half-hearted (or worse - a highly detailed) comment.

If there was ever 'code smell', it's when you see "x = y; // verbose way of saying sets x to y". And this is exactly your example - a verbose description of "$.resize.delay = 16;" If renaming variables and functions in this case doesn't make you feel better, I don't see why a comment would.

But yes... of course comments are important and needed in some cases, which I admit. However when they do, as other posters here have mentioned, it's usually annotating why, not how/what. I can't think of many reasons why it's not a bad sign if you find yourself explaining how something works - the only one that comes to mind is with hand-optimized code.