These days I often write the class/method level documentation before starting on the code. This is particularly helpful in keeping classes well defined and methods single-purpose, because you have a reminder right there in front of you that will tell you when your class/method has evolved outside beyond your original intention.
I don't like writing documentation any more than anybody else who can write code, however I don't find that it eats coding/debugging time, as the act of explaining back to yourself what you are about to do is all about improving the output from your thinking time.
Method comments also provide a useful double check, because if the code doesn't do what the comment says it does, then that's something worth looking into when debugging.
From a code reader's perspective, since useful code will be read many (hundreds/thousands) more times than it is written, comments that document the code contract save the reader from having to work out what the code does at the next level of detail. When you're skim-reading many thousands of lines of code this saves expensive mental context switches from skim reading to analysis and back.
The people who spend a large part of their working day reading large amounts of code are the team-leaders and architects who are responsible for keeping the systems working, and negotiating with management on behalf of their development team(s). Even well written code is hard to read quickly and in quantity, because the bulk of it will be at a different level of abstraction from the level that the reader is interested in.
If the people who represent the development teams can't read the code quickly, it's hard to have evidence-based discussions with managers, and decisions are made without being influenced by the technical realities.
Repeated many times over, this leads to difficult issues for the development team, which could have been avoided by applying a bit of engineering discipline at the detailed level.
Not all systems are large, complex and short on gurus who just know the answer, but some systems are like that, and they can get that way suddenly. The next generation of gurus-in-training will thank you for documenting your code.
