The following are a few principles that I try to follow:

• Everything needs documenting.
• It is better to document as part of an artifact where possible e.g. inline.
• Documentation is for the reader.
• Document as part of the process e.g. during architecture selection, whilst coding, when deployment scripts are generated. Documentation after the fact is often poor (I am ignoring proper user manuals here).
• Don't repeat yourself (DRY Principle) e.g. in code comment on the whys not the hows as the code does that.
• Only document what will be useful to someone else in the future e.g. discarded options are only worth documenting if there is a need to highlight that it should not be selected again (including why) - DO NOT LEAVE COMMENTED OUT CODE AS COMMENTS "JUST IN CASE" as that is what VCS is for. The development process is of little interest to the maintainers - although it may be a higher level artefact for a project retrospective.

FYI I am a big detractor of the programming style where people believe that by careful naming of classes and methods alone is enough code documentation. Naming is essential but is just one of the multiple techniques that should be applied to documentation.