Out of pure coincidence, I stumbled across this blog post about Technical writing in 2049 by Fabrizio Ferri Benedetti as I reviewed some examples of my earliest technical writing. I thought this might be a good opportunity to reflect on the past to see into the future.
My oldest artifact of technical writing that I authored is a technical manual for a central patient monitoring system I built for a hospital in 1981. The oldest technical manual I could find in my library is an Air Force training manual from 1952. I’ve kept some other relics of technical writing, but most are still in boxes.
Fabrizio’s blog post ends with this line, “What do you think tech writing will look like in 2049? I’d love to hear your predictions!” With my historical artifacts in hand, I accept his challenge and offer this response.
While I can only imagine what I thought about the future in years past, I can use these artifacts as examples of where technical writing has been and where it might go. I can also use them to describe how hard it is to predict the effects of a technical disruption, except by saying, “The more things change, the more they stay the same.”
Tech comm 1999
25 years ago, we still mostly printed the tech docs in books, as we had done in the decades that preceded, although online documentation was clearly about to make its debut. For a short while, CDs replaced printed docs but soon after, tech docs were almost exclusively served online. Could I have imagined online docs in 1999? Probably, without too much imagination. After all, we already had AltaVista.
To look at the past, present, and the future of technical writing, I think it’s best to tease that apart into content, production, and use or audience.
I’ll leave out stakeholders, because I haven’t seen that change much since content went online and the business model for technical writing all but disappeared. That’s a conversation for another article.
Technical writing content
Over the decades, writing technical writing has changed very little. The subjects, of course, have changed. While it’s quite possible that technical manuals about the “Theory and Use of Electronic Test Equipment” will continue to be written, it’s unlikely that recent editions will talk about vacuum tube amplifiers as much as my 1952 manual explains. However, I’d argue that the method of explanation is likely to be very similar to the method used in 1952.
Likewise, the API reference topics and software procedures found in 1999 and earlier technical content bear a striking similarity to those found in current web content even though the more recent topics aren’t going to refer to Window NT functions (except for those that are still supported, of course).
I’d attribute this similarity to the fact that people are still people, and they learn in much the same way as they did in the past. As Carroll described in 1990, people just want to see what they need to see. Nothing more. Nothing less. For my tenure as a technical writer, finding that sweet spot, and then adding in what the content they didn’t know they needed, has been the most enjoyable challenge of the job. I don’t see that changing in the future, so long as the technical writer’s audience continues to be people. The content that we see today is the result of decades of evolution and adapting to our human audience.
Technical writing production
How technical writing is produced and distributed has changed considerably since 1999 and is probably the most volatile of the categories. My 1952 manual is printed on paper with two columns of text to keep it easy to read—a feature that is also the result of centuries of evolution. I would imagine that the manual was written as a manuscript, typeset, and published as any other book was—all of which are technologies that predate my venture into professional technical writing.
To illustrate that with my artifacts, my technical manual from 1981 consisted of hand-drawn schematics and type-written content, with some photocopies of related content. It was a very low-budget artifact. Another manual I co-authored in 1988 consisted of word-processor output using some antique markup language with a few graphics generated on a Macintosh mixed in. Still in the low-budget end of the spectrum.
Moving into the 90s, I wrote manuscripts that would later be typeset. When I returned to tech writing in 2004, after a brief excursion into film making, the content moved to CDs and, eventually completely online.
Production of the content, perhaps because I was working at Microsoft, was initially done in Microsoft Word, but later moved to a series of arcane authoring systems to support the even more even more arcane publishing systems. A pattern that has continued to this very day—in the past 25 years, I can’t recall using the same publishing tools on more than one job. The driving force tends to be where the authoring system we used is largely defined by the production and publishing system that was in place.
What does this look like to me going forward. I think authoring systems will continue to be the tail of the dog, where the dog is the publishing and production system (much as it has always been). If a publishing system comes along that can read your mind, technical writers will have USB ports installed to author the content. Right now, technical writers write content for an audience that reads it from the web. If AI becomes the publishing system through which content goes to get to the user, then we’ll write content to feed the AI.
The technical writing audience
I don’t see the audience changing much in terms of their goals and incentives, so long as the audience remains human. If the audience becomes just the input to AI, then I struggle to imagine what that would look like, but nothing I can imagine seems very fun.
The audience drives everything. They read content on the web because that’s where content comes from these days. Just like 25 years ago content came from well-organized, well-indexed, and generally pretty expensive printed books. I watched the transformation from books to web content take place in real time during the double-oughts. As more content was accessed through the web, more content was published on the web. Technical content was no exception. If AI becomes the way people get their information in the future, then technical content will migrate to it just as it moved from hand-written volumes to typeset books to CDs to web pages over the centuries (I contend that the scribes who wrote books of spells for their sorcerers were the first technical writers, but I digress…)
Back to the future
I don’t see the need for technical writers disappearing any time soon (recent layoffs notwithstanding). I also don’t see business decision makers getting any more enthusiastic about paying for technical writing than they are at the present.
Right now, we’re seeing the “free” version of AI where its true costs are heavily subsidized, and it still costs more than most technical writing budgets are ready for. When AI features need to pay their own way, it could be even further down the road before they are available for everyday technical writing use.
Even for API reference topics, the technical writing domain that seems most likely to be automated, history has shown that good reference topics still need a human touch somewhere in the process. Whether that human is the designer who spec’d the API, the engineer who wrote the API, or a technical writer who documented it after the fact, is an implementation detail. Currently, having a technical writer do it generally provides the best-quality content for the price. AI generation of more complex content like conceptual, overview, and tutorial content seems even further into the future.
This isn’t to say that all technical writing couldn’t be replaced by an AI engine of some sort. Just that to do that would require more up-front design and documentation than is currently produced. Our current form of having just enough engineering to produce a viable product accompanied by just enough documentation to make it usable by a large enough market is the most efficient way to create and document software products. Until that balance changes, I don’t see AI doing more than assisting the human technical writers in the process.
Bottom line
The writing aspects of technical writing will continue to be as important for practitioners as they’ve always been. Know your audience and know how to give them the information they need when, where, and how they need it. I suspect Carroll’s guide to writing procedural content will be as valid for the next 30 years as it was when it was written 30 years ago, for example.
The technical aspects of the content and the production will continue to change with the prevailing technology. I don’t think that technical writing will lead any significant technical change, but it must certainly continue to keep up with it.
One Reply to “A look at the past to see the future of technical writing”