This should be a prerequisite, but is half the battle with a lot of code. The rest is explaining how all those descriptively-named functions do what they do, why they do them in a specific way, and known issues and gotchas. But generally, the more human-readable meaning we can impart to the actual commented code, the more meaningful our stack traces, logs and diagnostics will be.
The more code can be written in an easily human-readable form without comments, marking the intended purpose and context of use, the harder it is to hide (and write) buggy code. See BDD, where one defines pre- and post- conditions for every function.
In an ideal world, we would express tasks in a precise declarative language, with the minimum of hints as to how to perform them, and the compiler/runtime would deduce the implementation. Unfortunately, Prolog and constraint programming languages have so far fallen short of this dream.
In the meantime - the 'what' should be in the code, the 'how, why and watch out' should be in the comments.