In late 2003, Apple released the iBook G4. The laptop had what Apple referred to as a “sleek, durable polycarbonate plastic enclosure” in the same matte grey of every computer of that era. It featured a 12-inch screen, a 1 Ghz PowerPC processor, and 256 MB of RAM.
For the purposes of this blog post, the iBook G4 is a useful example, because it’s still recognizably a modern computer. I don’t have to talk about storage in KB or use the word “baud” when I mention its modem. It has a wireless ethernet card and the same Unix-like operating system that powers modern Apple computers.
Despite its modernity, here is a downright archaic excerpt from the user manual of the late 2004 model:
The trackpad is sensitive to how quickly you move your finger. To move the pointer a short distance across the screen, move your finger slowly across the trackpad. The faster you move your finger, the farther the pointer moves on the screen.
For best results when using the trackpad, keep in mind these tips:
- Use only one finger.
- Do not use a pen or any other object.
- Keep your finger and the trackpad dry. If the trackpad becomes moist from humidity or condensation, gently wipe it with a clean cloth before you use it.
The documentation for the 2019 model of the MacBook Pro contains none of these helpful tips and is instead devoted to gestures. What happens if you swipe left with three fingers or push hard with one finger? It doesn’t need to cover the concept of acceleration or warn people not to scribble on the trackpad with a permanent marker. In the past 16 years, humanity has crossed that bridge. People understand how to use a trackpad. Apple’s technical writers only have to document the non-obvious, hard-to-discover behaviors. In time, some of those gestures might become ubiquitous. Some already have. Think about pinch to zoom or swipe to scroll.
All enduring technologies follow this path. The need for great documentation decreases as products mature and audience understanding increases. The same developer who throws out the manual to a new vacuum cleaner might spend hours scanning the Python documentation. People don’t ignore documentation. They read it in vast quantities. But people do ignore excessive documentation of well-understood subjects.
The essential trait of a long-term successful technical writer, then, is the ability to continue learning new technologies and tailoring documentation to the needs of today’s users. It’s an amazing profession. We get paid to learn new things over and over.
The goal of all this learning is to blur the line between subject matter experts and technical writers. Writers have to be knowledgeable about a given subject in order to coherently create and organize content. Rather than pursuing a degree in English and trying to “break into” a field, today’s aspiring technical writers should get a degree that qualifies them to work in a field—computer science, biology, chemical engineering, architecture—and minor in a writing-heavy discipline like English, psychology, history, political science, or journalism.
Students shouldn’t be looking for technical writing jobs. They should be looking for technical writing jobs in a growing industry that interests them. Being a technical writer at a construction firm doesn’t suddenly qualify you to write at Google, in the same way that producing documentation for Microsoft doesn’t make you a shoo-in for a career at Pfizer.
According to the US Bureau of Labor Statistics (BLS), the software industry has the brightest outlook for technical writers. Software developer jobs are expected to grow by 26% by 2028, which makes it one of the highest-paid, fastest-growing professions in the United States.
Sure enough, technical writers are doing well, too, with 8% growth by 2028. But this number feels a bit disappointing, especially when compared to the 26% for software developers.
It turns out that technical writers are doing better than the numbers suggest. Together, the following three sectors employ 61% of all technical writers in the United States.
Professional, scientific, and technical services
This sector is knowledge work: legal, accounting, engineering, consulting, research, and computer services. Total growth for technical writers in this sector is 18.1% by 2028.
This sector is “any transformation of materials, substances, or components into new products that doesn’t qualify as construction.” Examples include chemicals, leather goods, appliances, furniture, electronics, machinery, and paper. Manufacturing in the United States is shrinking. By 2028, BLS predicts that the sector will have 5.1% fewer technical writing jobs than today.
This sector is publishing and distribution: motion pictures, sound recording, broadcasting, telecommunications, and web search portals. It’s a case of extremes. Newspaper, periodical, and book publishing are way down, as is telecommunications. Software publishing and data hosting are way up: 19% and 21.3% by 2028, respectively.
These numbers—18.1%, 19%, 21.3%—aren’t far off from the number for software developers. Growth within technical writing is huge if you’re in the right field.
This continued concentration of technical writers in the software industry has led many inquisitive, well-meaning people to ask some existential questions: should we be worried about automation? Can bots replace technical writers?
The short answer is no, not in the near future. The longer answer requires us to compare what we do on a day-to-day basis to what AIs are currently good at.
AIs currently operate at their best in narrow domains. By “narrow domains,” I mean ones with a small set of well-defined rules: telemarketing, games, driving, financial transaction analysis.
Consider chess. Yes, an AI has to do a huge amount of branch prediction, but the average number of valid moves you can make on a chess board is 37. In Go, it’s between 200 and 250. Ultimately, though, the only decision a bot can make is where to place a piece on a board. Likewise, in driving, you can accelerate, brake, reverse, and turn. There are many reasons why you might select one action or another, but it’s a narrow domain.
In other words, the machines of today that we view as so incredible—and to be clear, they are incredible—are highly specialized, narrow in focus, and not particularly smart. They need teams of developers to provide them with vast amounts of high-quality data in order to learn skills, and even then, they need extensive maintenance and tuning. As Guy Suter, the founder of an AI startup noted, “This isn’t general purpose intelligence…. [AlphaGo] couldn’t just wake up one morning and decide it wants to learn how to use firearms.”
To answer why people are so fixated on AI and automation, though, we can discuss something a little different: the venerable institution known as the United States Postal Service.
In 1952, a freshly-elected Dwight D. Eisenhower appointed a man named Arthur Summerfield to be the 54th Postmaster General of the United States. Summerfield wasn’t appointed due to any particular expertise in shipping or logistics. He wasn’t a career civil servant. He was a product of the spoils system. He was a failed politician who owned an auto dealership. He also happened to be chairman of the Republican National Committee and instrumental in getting Eisenhower elected.
In 1959, as an experiment into new delivery methods, Summerfield placed 3,000 identical letters into a cruise missile, had the U.S. Navy load that missile onto a submarine, and then fired it at a naval air station in Florida. I assume the logic was that if the missile went off course or malfunctioned, well, it’s just Florida.
The missile landed as intended with all mail intact. Summerfield was elated. He said, “Before man reaches the moon, mail will be delivered within hours from New York to California, to Britain, to India or Australia by guided missiles.”
I’m not going to mock Summerfield. I’d have been excited, too. The important point here is historical context.
Summerfield was born in 1899, so he was a teenager through most of World War I and in his early 40s during World War II. At the time of his appointment, the United States was five years into the Cold War. During Summerfield’s lifetime, rocketry went from essentially science fiction to the German V2 rocket being used in the late stages of World War II. Summerfield held the Postmaster General position from 1953 to 1961, the start of the space race.
So you can imagine that a forward-thinking person of that era might view rocketry as this transformative, thrilling, limitless technology. The American philosopher Abraham Kaplan coined this tendency “the law of the instrument” in 1966, which goes like this: when you’ve got a hammer, everything looks like a nail.
Another way to think about it is as “extrapolated technology.” The idea is that humans are prone to seeing the progress and direction of a technology and expecting it to improve forever along that trajectory rather than slow down, change course, or be disrupted.
In 2013, two researchers at Oxford published a ridiculous article called “The Future of Employment” that relies almost entirely on extrapolated technology for its conclusions. We use machines to help optimize some low-level code, therefore we will eventually use them to write all code. Siri can turn on the lights in my house and set appointments in my calendar, so executive assistants everywhere are doomed. The logic doesn’t track. The article lists technical writers as having an 89% probability of being computerizable, the same percentage as sewing machine operators and bus drivers.
Thankfully, an article from McKinsey and Company takes a more nuanced, rational point of view. The authors argue that “predictable physical work” and “office support” will be the hardest-hit categories in the United States by 2030. The big takeaway here is the same as it’s been since the beginning of the industrial revolution: if your work is highly repetitive and narrow in scope, you’re at risk.
On the other hand, McKinsey expects technology professionals to be one of the top growth areas. The reason I highlight these two areas, office support and technology professionals, is that some technical writing roles fit into the former and others the latter.
If my job was “take content from engineers, edit it for clarity, and send it back to them for review,” I might be worried about my long-term job prospects. But that sentence doesn’t describe my job at all. Compared to narrow domains like Go or telemarketing, today’s technical writers operate in broad domains. We test new features and their interactions with existing features, add content based on that behavior and the ever-changing needs of the audience, modify existing content as new features replace or deprecate old ones, consider the broader ecosystem in which products exist, write sample code, style pages in a user-friendly way, give presentations, compose UI text, review pull requests from the community for accuracy, and troubleshoot customer issues. The job requires careful prioritization and frequent deep dives into complex problems.
Certainly AI has the potential to make technical writers more productive—think machine-generated translations into a dozen languages, narrowing hundreds of candidate writing samples down to the top 10 candidates, on-the-fly suggestions for the sentence you’re writing based on surrounding text, auto-generated reference materials—but if you have expertise in software and continue learning throughout your career, you’re not getting replaced by a bot any time soon.
But let’s say you disagree with me. You believe that, by the end of my career, a bot will be able to do my job at least as well as I can and won’t have pesky needs like eating and sleeping.
Well, I have another relevant quote from Summerfield: “The great progress being made in guided missilry will be used in every practical way in the delivery of the United States mail.”
I like this quote because it’s 100% true. Guided missilry was used in every practical way in the delivery of the United States mail. There just didn’t happen to be any practical ways. There are no technological hurtles preventing us from realizing Summerfield’s glorious vision of missile mail. The problem is that it doesn’t make economic sense.
Even if all of the job functions of a technical writer can hypothetically be automated at a satisfactory level, how many developer hours would it take to create such an AI? Let’s assume it would take a team of developers multiple years and might only be effective at doing my job, not yours. And remember, software requires ongoing maintenance to work properly. How many developers would it take to fix bugs and add features to such an AI? What about ongoing operating costs? The first competitive version of AlphaGo used 176 high-end GPUs, which have an upfront cost of around $100,000 in addition to related parts, installation costs, power draw, and component replacement over time.
Even if it were technically feasible to replace a technical writer, it almost certainly wouldn’t make economic sense and won’t for a long time. Beyond a certain, unforeseen technological horizon, I concede, yes, all bets are off.
Some earth-shattering breakthrough could materialize and wreck all of my predictions here, but that’s not the way computing has ever worked. We build on top of existing innovations, bit by bit, library by library, combining new technologies in novel ways. 16 years later, the computers of today aren’t doing anything fundamentally different than the iBook G4. They don’t even look different.
If we focus on the evidence available to us today—what humans are good at, what machines are good at—there’s just no cause for widespread concern in the field of technical writing. From now to the end of my career, I’m not worried. If you’re working today and regularly get your hands dirty when creating documentation, you shouldn’t be, either.