In a former life, I was a technical writer. Scratch that, I was a damn good technical writer, the lack of appreciation from one Southeast Michigan-based employer not withstanding. I dreaded every minute spent writing a manual, help system, or technical spec. But I was damn good at doing it.
That said, it's not hard to be a technical writer. It is hard to be a good technical writer, however. So, to all you struggling tech writers, take this small piece of advice from a tech writer turned pseudo-developer/business process analyst: every blurb of documentation you put out should lead to a measurable outcome. Yes, you have to do the expository "this is why we built it this way" crap, but if I can't act on the information you put out, that information is worthless - documentative lint, if you will.
This post brought to you by two weeks of frustration caused by bad documentation. Frustration, I might add, that was cleared up by a 5 minutes phone call with a very accessible Subject Matter Expert.
Man is the only animal that laughs and weeps; for he is the only animal that is struck with the difference between what things are, and what they ought to be. - William Hazlitt
Subscribe to:
Post Comments (Atom)
What is that noisy IoT device on my network?
That's the first question that popped up when I installed AdGuard Home on my Raspberry Pi last night. Within minutes, hundreds of querie...


No comments:
Post a Comment