As a rule, I've always hated writing documentation of any kind. I feel it takes valuable time from developing functionality and maintaining existing functionality.
However, over eight years of consulting, I have found that I despise even more having to work on an application for which not only is there no documentation, but the code itself is badly written, without any functions or subroutines to help clarify what is going on and why.
So, after all that time, I admit writing documentation is a necessary evil.
Yet, I am more interested in code that is rather easy to comprehend. There are different ways of writing code, whatever the language used. One is to pile line upon line of hopelessly entangled instructions that will invariably elicit (in the mind of the next guy who it fell on to modify) a gut reaction calling for a complete rewrite.
A different way is to break the procedure into steps, break the steps into smaller portions, and code the little bits into bigger bits into a main sequence that, suddenly, becomes much more readable.
By doing that, and commenting code when useful (;need to get resource A because field X has category info), you can almost dispense with writing a full documentation for the next guy. If he is worth anything as a programmer, reading your code will TELL him clearly what is going on and why.
Clear code is more important than documenting a mess. Of course, the best situation is having code that is clear to read, and documentation that outlines all the procedures, the function calls, and the scope not of each function (that should pretty easy to determine) but of WHY that function/procedure is necessary.
More and more I find that it is not the CODE that needs documenting, but WHY the code was written in the first place.
Of course, writing anything still requires time.
Pascal.