I work for the US Government and have for 15 or my 20 years programming. When I was first starting I hated documenting anything other than the inline comments I placed in code. I've been fortunate to work on large projects where there was staff to handle the "formal" or System and User documentation, but still we had to provide the basics to the documenters.

After many years of both being at the beginning and ending of projects and in the postion of assuming the work of other developers I have learned the value of documentation. Even on small projects I maintain Code and System (still not real big on producing user documentation) documentation to the level I would like to have if I suddenly had to pick up the project with no overlap of personnel (it does happen on small and medium projects). The documentation must be written to the level of a Junior programmer (not a novice) but much more detailed than an expert needs. Reviewing the documentation available is as much a part of the Code Review process as is looking at the code itself. If the code is not well documented how do you know the programmer intended for the code to do what it is doing?

On a seconday note: When a system crashes there needs to be documentation that can answer any question needed without a having to "dig" through code. It is espically important to have a very strong Disaster Recovery Plan the can return a system to operational status quickly at a new site on new equipment. I'm always amazed everytime I run our DRP to find how many little "gotcha's" there are in getting a system back up and running at a new location. But at least I know if I have to, I can, and most likely any "recovery" required will be much less in scope than we practice for and I'm confident of success.