TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
One perspective that I haven't seen mentioned:
While a software is being produced, there is limited time to explore and
understand how to apply the product to practical situations. There is
usually only time to understand how the product functionally, which is why
so many product manuals are organized by menu items instead of by tasks.
After the product ships, there is time to apply the product to real-life
tasks and produce documentation that is more task-oriented and detailed.
I've purchased stacks of aftermarket books for products I use regularly,
such as Microsoft Excel, because eventually there is some particular thing
I want to do that is not addressed in the original manual as an individual
task, for example, how to write a VBA macro that transfers dates from
Excel to Microsoft project.
So, I don't view these books as primarily a way to get documentation for
pirated software, although I'm sure they are used for that purpose. I also
don't fault the writers of the original product documentation for not being
able to become expert in 100% of the product and document every conceivable
task before the ship date. This does not, of course, excuse product
documentation that is just plain poorly done; but I've never been able to
learn a complex piece of software thoroughly without third-party books.
