3 ms·
> I find it really terrifying that somone who's only a "technical writer" would be writing the published documentation of such things Why? Are you suggesting t
by tasuki 8y ago
> I find it really terrifying that somone who's only a "technical writer" would be writing the published documentation of such things
Why? Are you suggesting that technical writers don't have enough understanding? Good technical writers have a thorough understanding of the product they're documenting. An ex colleague of me switched from being a software developer to a technical writer. He very much understands things from a software developer perspective.
As a software dev, I'll take docs written by a technical writer over docs written by a software dev:
- Writers can organize the docs better, will avoid wall-of-text rambling.
- Writers can write (they eg know the difference between "pouring" and "poring").
- wenc 8y agoAnother advantage: Technical writers write from the perspective of users. Devs are sometimes too close to the code (too much scaffolding and presumptions) to understand what the user’s experience and thought processes are like. Technical writers can bridge that. Writing as a process also helps expose gaps in thinking — in this case, in the user facing implementation. This feedback can in turn be useful for devs. One example of where technical writing can help is PySpark. Because Spark is JVM centric, it can be relatively difficult for Pythonistas to get started with unless one already knew how things were laid out. I had to read multiple tutorials to set things up the right way before “import pyspark” would even work. Not to diminish the tremendous amount of efffort that has gone in the Spark docs, but that is one area where a good technical writer could add a lot of value. Side note: “findspark”, for the trivially simple package that it is, simplified getting up and running with PySpark. But I had to find out about it through a random tutorial.