Part One: Writing

[lief-erickson]

No matter what else you learn or forget about the work of technical documentation, remember as much as you can about writing and writing technically. The rest changes a lot from gig to gig, but the need for clear, concise, and compelling technical content will remain. Documentation workflows and methodologies, platforms and toolchains — all the stuff you need proficiency in to call yourself a DocOps practitioner matters not at all if you cannot write complete, accessible product explanations and instructions.

I disagree. A writer who does DocOps may need to remember that, especially a lone writer who also has DocOps responsibilities; but someone, say a developer or information architect, for whom writing is not a core job responsibility will not need to heed this recommendation, even if good writing skills are still beneficial for other reasons.

[briandominick]

Yeah I think I agree with this now as well. I'm trying to get out of writing, though I was not when I wrote that, and I had never met anyone who just does DocOps. Now I have, and I am, so sure this should change. There is probably a lot of audience shift throughout that needs to be tightened up.

[briandominick]

To be clear, I still want to write this book and others and document all my own products, etc -- professionally I am trying to avoid writing about other people's products. I did not know that was an option when I started this book.