While there are certainly larger, more important issues about which I can rant, I’m sticking with something personal.
In a meeting this morning (yes, Wednesday; I know I’m late), someone brought up the issue of bundled third-party documentation, and how he thought it appropriate that our company’s writers should be responsible for those docs. Because, you see, we could be held liable if the docs were wrong. Evidently, he hasn’t heard about disclaimers, but, sadly, this is an issue with which I am familiar.
Of course, objections abounded. If there was a problem, what were we supposed to do? Sun probably wasn’t going to hand us their doc source files. And I’m damn well not going to review another company’s doc unless they’re going to put me on the payroll. Someone suggested that we might as well be liable for the code, too.
As I said, I’ve heard this before. I’ve heard similar arguments in every single company that I’ve worked for (five, so far). At company #1, I was tasked with incorporating some third-party docs into our doc set. Those other docs were terrible. Not only was the grammar and style woefully incompetent, but each chapter opened with a happy little story about Jack and Jill using the product, including banter that someone must have thought witty but that was actually painfully stupid, bordering on twee. As it happened, the product itself was complete crap, but it took the resignations of three developers to kill the project.
At companies #2 and 3, the suggestion was to include instructions on setting up Oracle and/or Microsoft databases. This idea, while obviously stupid, kept coming up. Stupid, because Oracle and Microsoft have huge stables of tech writers (including me, now) working on shelf-loads of books; stupid, because neither Oracle nor Microsoft had me on their payroll; stupid, because if our customers had Oracle or Microsoft databases, then they had all of the docs they needed; stupid, because I was occupied with writing manuals for our own company’s products.
Why the hell does this keep coming up? If I work for, say, Oracle, why the hell should I be expected to write instructions for configuring Apache? Now, yes, I’ll happily write instructions if they relate specifically to our product. Need certain values to get IIS to work with our product? Fine and dandy. Want me to write an A-Z guide on configuring ISS? No way in hell.
The problem, I believe, is that people not in the know think that writing doc is easy. Coding? Yeah, that must be difficult, because the execs probably don’t know how to write a function, or haven’t done so in years. But docs are in English, and anyone can write “Enter a name. Enter some values. Finally, click OK.” No problem.
Except, of course, that if I’m not writing, I’m installing the product, running the product, figuring out how a user can screw up the product, entering bugs, and cornering developers to dig information out of (lately, they’ve been trying to hide it in their spleens).
Now, yes, I do have time when it appears that I’m doing non-work stuff. Like, for instance, writing Cants. But that’s only because I have an odd, spastic working style, which involves intense but irregular flurries of writing. A paragraph here, a section there, off to snare a QA person, then a check of wargaming miniature news. Doubtless this applies equally well to developers, QA, and others who do real work. Sales and marketing types probably do something similar, except that they polish their hair and practice their “Trust Me” smiles in their off minutes.
So, yes, as far as job hazards go, it’s not as bad as exploding power transformers, but it’s fairly annoying. So stop asking, dammit.