Interesting read, though the writing itself is ironically quite clunky for an article
about writing. It's bad enough that I still suspect it
might be written by an AI.
It's worth noting that technical writing is basically two professions wrapped up into one:
- On one hand, there are traditional technical writers; folks with next to no coding skills who frequently edit technical content written by others. These individuals typically use a CMS to produce content (since they have very few technical skills), use Google Docs or Word to edit and create content, and make money in the range indicated by the article.
- On the other hand, you'll find, er, "technical technical writers." These are typically former developers or senior writers who do a lot of coding on the side. They generally practice docs-as-code, write novel content with only technical reviews as input (instead of editing content written by the developers), and also serve as QA and beta testers. Organizations often rely on these kinds of writers as the first users who aren't internal developers for new features, and they can be trusted to explore the bounds and edge cases of a new feature all on their own, with only occasional questions and meetups with engineering. They also frequently hack on documentation frameworks, writing extensions and layers on top of sphinx, docusaurus, markdocs, etc. They make near-developer salaries, sometimes even more.
As we lose testers and QA, and engineering organizations endure more and more hiring freezes, the latter class of technical folks become more and more valuable. It'll be interesting to see where the industry goes over the next few years. I'm tempted to say that docs-as-code scales better than collaborating on Google Docs, but who knows?
This article, unfortunately, is completely targeted at the traditional class of technical writers. See their recommendation on running your own blog:
The first step in creating your own blog is deciding on a
content management system or CMS that will help you maintain
your blog posts in one place without having to worry about
technicalities like formatting HTML code or writing css or
get busy with the back-end. You can start with any of the
following: WordPress, Wix, Ghost, Squarespace, Strapi or Sanity
Besides the fact that the first sentence is so long, rambly, and has enough structural issues that I don't believe a competent technical writer would ever craft it... this seems really close-minded to me. I personally use Jekyll and GitHub Pages for my personal blog, so I don't have any CMS besides a GitHub repo. If you're currently a developer, I recommend that approach -- it's closest to the docs-as-code documentation approach, too. Additionally, this quote commits the sin of conflating "using a CMS" with "writing posts in something other than HTML". Hopefully non-technical folks interested in technical writing don't get too confused by it.
It's worth noting that technical writing is basically two professions wrapped up into one:
- On one hand, there are traditional technical writers; folks with next to no coding skills who frequently edit technical content written by others. These individuals typically use a CMS to produce content (since they have very few technical skills), use Google Docs or Word to edit and create content, and make money in the range indicated by the article.
- On the other hand, you'll find, er, "technical technical writers." These are typically former developers or senior writers who do a lot of coding on the side. They generally practice docs-as-code, write novel content with only technical reviews as input (instead of editing content written by the developers), and also serve as QA and beta testers. Organizations often rely on these kinds of writers as the first users who aren't internal developers for new features, and they can be trusted to explore the bounds and edge cases of a new feature all on their own, with only occasional questions and meetups with engineering. They also frequently hack on documentation frameworks, writing extensions and layers on top of sphinx, docusaurus, markdocs, etc. They make near-developer salaries, sometimes even more.
As we lose testers and QA, and engineering organizations endure more and more hiring freezes, the latter class of technical folks become more and more valuable. It'll be interesting to see where the industry goes over the next few years. I'm tempted to say that docs-as-code scales better than collaborating on Google Docs, but who knows?
This article, unfortunately, is completely targeted at the traditional class of technical writers. See their recommendation on running your own blog:
Besides the fact that the first sentence is so long, rambly, and has enough structural issues that I don't believe a competent technical writer would ever craft it... this seems really close-minded to me. I personally use Jekyll and GitHub Pages for my personal blog, so I don't have any CMS besides a GitHub repo. If you're currently a developer, I recommend that approach -- it's closest to the docs-as-code documentation approach, too. Additionally, this quote commits the sin of conflating "using a CMS" with "writing posts in something other than HTML". Hopefully non-technical folks interested in technical writing don't get too confused by it.