I know that philosophy well, but I do not really agree with it - not at all. For example in concurrent code written in C, the way things are synchronized is normally implicit. You can understand it if you read all of the code, but not by looking at single functions. If you add accesses without proper synchronization, you will get quickly undefined behaviour which can cause extremely nasty concurrency bugs.
I also agree with the several comments made that it is often more helpful "why" something is done, than "how". This is, of course, valid for in-code comments as well, but IMO equally important in overview documentation.
> And 80% of all »projects« lack at least one of the points above.
Yeah, I know. In fact, I have rarely seen good technical documentation.
The rest is in the code. And 80% of all »projects« lack at least one of the points above.