Re^3: What sets Perl back

Most good programmers write some really crappy documentation.

[snip]

but even if the programmer could manage to write something, it goes against just about everything most programmers hold valuable -- saving time.

It's, of course, actually a time saver in the long run to write good docs.

Good docs make it easier for *others* (co-workers? folks on the qa team? do-gooders in the free software community?) to work on your code rather than you having to do it yourself,
Good docs save you time when you need to re-familiarize yourself with your own code that you may not've touched in a while

Personally, the first thing I look for in a free software project is good docs. If the docs are good, you can always write tests and fix or update the code as-needed. If the code is ok, but the docs aren't good, the software is (in the long run) only useful to those who are willing to pore over it and try to figure out what it's supposed to be doing.

Comment on Re^3: What sets Perl back

Replies are listed 'Best First'.

Re^4: What sets Perl back
by jhourcle (Prior) on Dec 12, 2005 at 13:55 UTC

Yes, I know good docs time saver, but most programmers I know don't write good docs -- they might be a fantastic programmer, but they couldn't write down a complete thought to save their lives -- for them, writing documentation is like trying to write a report in high school -- a whole lot of work for relatively little payback (why do the extra effort for a '100' grade, when a '90' grade shows up the same on a report card? And hell, if the '70' is 1/2 the effort, it's still a passing grade)

There are those folks who can bridge the two fields, and there lots of 'big names' out there, who both program and write books professionally, but there are a whole lot more who are the folks in the trenches, writing code day in and day out. If you have an asshole manager bitching that you're behind schedule (mostly because they kept assigning you to other 'emergencies' that kept popping up, and they set the damned schedule before they even asked you what it was going to take to complete), documentation gets dropped.

I have a long running joke from one of my past jobs, where I have specifically listed in my notebook that documentation was listed as 'phase two' (we never got to phase two -- the job got implemented, and I moved on to other projects) In many places where good programmers cost money, it's not cost effective in the eyes of idiot management to have the lead programmers write documentation.

Luckily, I don't work for those types of places anymore, and I get to write documentation in a mostly timely manner, but when I'm buckling under, trying to prep for a release (typically dictated by the timing of AAS and AGU meetings), I'll focus on the code, and the documentation might get behind.

[reply]


good chemistry is complicated, and a little bit messy -LW
	PerlMonks