When I write code I generally spam it with comments to start with so I can follow my own train of thought (of course not useless comments such as "increment i"), and then I strip the comments I find redundant or obvious and am generally left with 2-3 comments per function maximum. Works pretty well for me. I like the first step because it allows me to easily see when I'm doing something wrong, because I won't be able to write a comment describing it explicitly.

I also never write a proper documentation until my library's architecture is set in stone (or at least won't be changed in several months) otherwise it's just an exercise in frustration shuffling things around every time you refactor. Until you've got a working design it's best to stick to personal, temporary comments (if you need any).

The most important thing I found is to not let comments fall out of date. If you change some code, then change the comment that's above/next to it to reflect your modifications. If you don't know what to say or don't have the time, delete the comment. Otherwise later on you or some user will go over all those obsolete comments and wonder what the hell you meant.

Test units are very important. Documentation is cool and all but often the best way to learn how to use a library is to look at a basic sample (which actually runs). It doesn't even take much time for the developer to write it and it's a huge help for everybody else, so don't neglect it. If a developer didn't develop a test unit for his library, then he simply doesn't care about other people using his library (unless it's a very specific library which doesn't lend itself to testing).