The new help system gives the appearance of being written entirely for Microsoft's convenience: so that that web content and on-line help could be identical. It's cheaper to produce.

This is a refactoring. It is a alleged improvement that should cause no change in functionality. Two things, then: One should refactor in response to "code smells", not in response to personal taste. In its 4.0 .NET release, Microsoft talks about making sure both languages have identical functionality. Maybe something somewhere in the past didn't work in C#. Is that still true? Is it something you need to do? Second, refactoring without unit tests is a high wire act. If the codebase lacks them, you are asking Fortune for bugs -- and she will deliver.

Psychologists have studied people winning the lottery for example. What happens is that one gets used to having more money. It's sort of like how one can feel acceleration but not velocity. The raise makes you happy; the salary not as much.

Maybe metaphors of motion would help, e.g., objects can enter new states or be carried or moved to them. Or you could refer to states being changed or altered.

This only sounds workable if (1) you never need to optimize anything for speed, (2) you don't have to credit anyone else's code, (3) no algorithms were harmed in the making of your software, (4) your code is single-threaded, and (5) your software doesn't do much more than move things around and apply simple transformations. Otherwise, sure, no comments. Why not?

Simple: consciously decide to write bad documentation first. Get going. Then go back and clean it up. Don't be afraid to have your first draft begin with a sentence that's leaden, cryptic, or awkward. When I do this, I often find that the "bad" version is much better than I thought it would be.