Technical writing in 2049

A month ago, Lana Novikova asked me to imagine the future of software documentation. What will software technical writing look like in, say, 2049, when our profession will be a century old? Will we be writing markup in git repositories or use ÜberDITA in space? Will our job still exist? I’ve put my futurist hat on to picture the shape of our profession 25 years from now. Buckle up!

From technical writers to technical therapists

Yes, our job will still exist, but, in most cases, it’ll no longer entail sitting in isolation in front of a text editor. The craft of tech writers will become more personal, more community-driven, and way more visible. As Alejandra Quetzalli explains in her book, docs happen in an ecosystem, in mixed human and software environments. It’s in those communities where technical writers will use their presence to heal the bonds between users who desire to better understand software, and software that will talk to us using the same language, trying to be helpful and failing.

If the move toward a more personal, quieter internet is going to happen, the need for warmer and more direct expertise will increase. In that sort of infinite Animal Crossing, tech writers will spend less time writing and caring about SEO, and more time playing the friendly NPC, showing possibilities and battling obstacles, acting as remote counselors or Twitch therapists, in the sense of a distributed, sometimes asynchronous group therapy that seeks to reconcile human and artificial agents. After all, we’re already doing that, albeit in drier, more formulaic ways.

What about the boring bits, like reference docs or step-by-step tutorials we’re paid to produce every day? In most cases, those will be left to large language models (LLMs) and their successors, only to be edited, checked, and optimized by tech writers. Software will tell more about itself by default, sometimes in ways that weren’t expected by their developers; our task will be to help software express itself when using human forms of communication. If you’re thinking of Dr. Susan Calvin, the robopsychologist from Asimov’s short stories, you’re quite right.

Docs as the Force that binds products together

Docs websites and manuals will disappear, at least for software, and that will be a good thing. Imagine a movie director saying that they want to improve the viewer’s experience by adding a soundtrack. Absurd, right? People will feel the same way if presented software documentation as a separate and optional deliverable. Instead, docs will be a trait of all software features, and an integral part of all human-computer interactions. Docs will disappear only to resurface everywhere, in the most glorious comeback of context-sensitive help ever to be witnessed.

In 2024 we’re still rewarding docs sites and focusing our efforts on getting docs up and running, as if we were creating primitive unicellular organisms for the first time. We can and will do better than this. The next stage of the tech writing’s evolution is to integrate with the bigger product lifeform, a step that will finally allow us to leverage things like true docs observability instead of flailing at useless performance metrics. Whether to hire a technical communications specialist will no longer be a question, as it’s no longer a question to have soundtracks in films.

It doesn’t really matter how technical or complex a software product will be. Documentation as a behavior of software components will consistently happen in CLIs, GUIs, developer tools, APIs, and other aspects of software. Wherever there’ll be points of connection between humans and software, there’ll be a need for meaningful, helpful words. If becoming a tech therapist requires merging technical writing with DevRel, the docs are everywhere paradigm will require tech writers and UX writers to merge into a unified professional role, the product writer.

Figma-ing documentation, or What You See is What You Read

By 2049, most discussions about which markup language is best will have become obsolete curiosities. The shift toward a product writing mindset will lead to a figma-ization (as in Figma) of docs editing, with the underlying format becoming an implementation detail that shouldn’t concern writers unless they need to fix something under the hood. We’ll spend more time editing docs together with designers in the same places, using the same tools, which will be able to deal with the most complex aspects of tech docs, such as reuse and modularization.

As I defended in The Pros and Cons of Markdown, if we’re using markup languages in git repos today it’s because of sociological reasons, not because it’s better than other solutions. We resort to docs-as-code as a way of embedding ourselves effectively to agile software teams and extract information faster, while getting docs tooling support as a beneficial side effect. This sort of commensalism has served us well so far, though it’s also led us to worrisome dead ends, such as the lack of good enough standards and a deep inferiority complex towards developers.

The combination of no-code/low-code development, LLM-assisted coding, and growing attention to design and user experience could mark the end of code as the primary medium for software documentation. This doesn’t mean going back to a Microsoft Word model, ignorant of the underlying structure; rather, it’s about going design-first, which is now enabled by tools that are well aware of coding needs and can produce valid, clean code out-of-the-box. In other words: knowing the JPG format doesn’t mean you’ve to draw pictures using binary code.

¡Viva la documentación!

By 2050, according to some estimates, the US will have more Spanish speakers than any other country. In fact, while English is still the dominant language for technical documentation, geopolitical and demographic changes might lead other languages, like Spanish, Mandarin Chinese, or Hindi to replace English as the primary language for technical documentation. This is not too hard to imagine, especially in a world that’s increasingly concerned with localization and internationalization of content. For all I know, we might end up using a new tech patois.

This prediction is perhaps the least likely to happen of all I’ve written in this post. I’m writing this as a speaker of English as a second language who routinely code-switches between English, Spanish, Catalan, and Italian while working at the same company and engaging with software developers and technical writers from the community. English still holds immense power and prestige as a technical language, owing in no small part to the strength of the tech sector in English speaking countries. It’s our tech Latin; displacing it might be impossible for centuries.

And yet, if the linguistic communities around the world realize the need to modernize the way their languages evolve and incorporates new jargon, they might be able to echo their own economic and technological growth, preparing for a future where they could benefit from similar prestige and attention in l10n and i18n processes. If you need figures to take this one seriously, read Xie and Freeman’s paper from 2019, where they estimate that 36% of all research from 2016 came from China. The increase of linguistic diversity in the web will eventually find its way to tech docs.

What do you think tech writing will look like in 2049? I’d love to hear your predictions!