So, IT people who get annoyed at having to write down step-by-step procedures about stuff...ever thought of convincing your boss (or yourself) to hire a professional to do it for you? Of course, that might be more effective than ranting about it in print...
Speaking as a technical writer, you know, one of those people who makes an avocation -- and, perchance, a living -- at discovering all the metacognitive awareness of software and then writing it down logically and sequentially, it certainly improves the user experience to have good documentation. Unfortunately, due to most programmers' lack of craft in the art of writing words (instead of code), and most PHB's lack of understanding that well-crafted documentation isn't just a loss-leader (why, it actually cuts down on tech support calls and makes users happy -- can't have that!), there's perishin' little good documentation out there.
The funny thing is, not only do technical writers have to have that intuitive grasp of new software (I've had clients give me completely undocumented late-alpha applications -- no notes, no rudimentary help, no source), but we also have to have the kind of skills that can take that gleaned knowledge and turn it into something useful without confusing or condescending to the reader, and/or falling into the dreaded "Comprehensible Only If Known" problem (the phenomenon whereby if and only if you already know how to do everything with the software, the documentation makes perfect sense).
Granted, a good help file, online tutorial, and quick-start help sheet laminated and stuck to the desk still won't solve the habitual "'RTFM' stands for 'Ring The Family Maven'" problem, but it's a start.
*cough* *ahem*
Speaking as a technical writer, you know, one of those people who makes an avocation -- and, perchance, a living -- at discovering all the metacognitive awareness of software and then writing it down logically and sequentially, it certainly improves the user experience to have good documentation. Unfortunately, due to most programmers' lack of craft in the art of writing words (instead of code), and most PHB's lack of understanding that well-crafted documentation isn't just a loss-leader (why, it actually cuts down on tech support calls and makes users happy -- can't have that!), there's perishin' little good documentation out there.
The funny thing is, not only do technical writers have to have that intuitive grasp of new software (I've had clients give me completely undocumented late-alpha applications -- no notes, no rudimentary help, no source), but we also have to have the kind of skills that can take that gleaned knowledge and turn it into something useful without confusing or condescending to the reader, and/or falling into the dreaded "Comprehensible Only If Known" problem (the phenomenon whereby if and only if you already know how to do everything with the software, the documentation makes perfect sense).
Granted, a good help file, online tutorial, and quick-start help sheet laminated and stuck to the desk still won't solve the habitual "'RTFM' stands for 'Ring The Family Maven'" problem, but it's a start.