It's definitely the easy way out for developers to skip (or skimp) documentation. It's like the seventh red-haired (step) child that nobody likes because it sticks out so much, takes so much time, takes away time from "true" work and is almost always considered an after thought once a project finished.

On the other hand a truelly well documented project is a treasure trove for developers - junior especially. With developers I mean not only the ones that have this title but all people who develop code on a regular basis - which includes most DBAs.

While senior developers most often use the in-code documentation to find out what their colleague intended to do to understand, replicate, improve the code for junior developers it is a first step to better programming. Certainly for me without the good in-code documentation I wouldn't be able to learn as fast on my own as I did over the last few years. A few lines more saved me countless hours of trying to figure out why.

This is especially true in my current job where I picked up from another developer - and his code was just the code with about 1 line documentation for 1000 lines of code. Without his comments (he luckily still works in the team) deciphering what certain lines of code do would have been difficult at least.

So as a start we did a drive to at least document our code base. Three weeks later this was done and proved fortunate when a new developer started in our team. Very much on the junior side he learned code pretty much from the comments within and the header at the start of the code explaining in a single sentence what the code was about and additional notes where things are not as clear as they could be. This developer has learned very well within three months and is now able to code fairly proficient and avoided a lot of beginner mistakes.

In addition (mainly because we code for a complex data warehouse project) we have additional documentation of how, why, what and where our project works. This is at a high level describing why we take what data from which server to achieve results, what can go wrong and how to rectify this. Granted, for the developers who work with this on a daily basis this is mainly in their heads and second nature.

For me this documentation was very good to have when I started and my estimate is that it saved me about 6 months poking through code and asking lots of questions and allowed me to understand my new job within a week. Where the documentation was not helpful I asked the right questions (and some dumb ones) and amended it.

So again this documentation helped the next new developer to understand within a week what his job is all about along with on-the-job training.

While such documentation is considered most often "wasted time" from the point of view of a new job start I can only recommend doing it. It may not help you directly but it will certainly help someone in the future (a lot). In addition during my last interview round I found that managers appreciated the level of documentation I had for my last system and it was certainly one of my strengths that landed me my current job.

Another area that developers try to avoid like satan the holy water is writing a manual. Granted, most of them are quite rubbish with it and most of them are down to a tick list of do this, then do that, then do the next.

While this provides a rough guide how to work a system I found that a bit of background information (about a page long max) helps users not only to do the job but take ownership of it too.

For example I recently had to develop a simple upload of an Excel file into a database. Basic instructions aside there was a quick description of how the system achieves this and some error descriptions. This pretty much saves me about 2 hours each month trouble shooting. Because the user understands what they need to check and they can do it for themselves.

All this for about 1 hour work writing the manual.

In my previous job a project was considered finished, when the helpdesk support told the manager that they have adequate documentation to support a new system. One particular developer had a project going on for six years taking about 3 to 6 hours each week away that he had to dedicate to support - simply because he hated writing documentation.

So for all developers who really really don't like to do documentation my advice is to do at least adequate in-code documentation (that means a header and lines for particular tricky stuff) and about 3 to 4 pages of what a system does at a high level. If required, put in some notes for the manual where and why things can go wrong.

This way when helpdesk (or a user) calls just tell them to look up the documentation (preferably on the Intranet) and call back if that doesn't answer the question.

That way allows you to spend more time on the perk of each development job.