Technical Writers

• Manual typewriter + mimeograph1940–1965

  Manual typewriter + mimeograph (wartime documentation era)

  The first technical writers worked with the same tools as any office professional of the era: manual typewriters, carbon paper for copies, mimeograph machines for distribution, and paste-and-scissors layout for diagrams. Documentation was physically produced: a typist typed the text, a drafter produced the illustrations, and a mimeograph or offset press reproduced the manual. The technical writer's craft was entirely in the research, the organization, and the language. The production constraint meant manuals were printed once and rarely updated; getting the content right before it went to print was the entire professional discipline.

  Effect on the work

  The production constraint kept documentation workforces small relative to the equipment they served. A single technical writer might be responsible for the full documentation set of a complex military system. Accuracy and completeness were the professional standard because errors could not be cheaply corrected post-print.

• IBM Selectric typewriter + phototypeset…1965–1985

  IBM Selectric typewriter + phototypesetting (production-quality documentation era)

  The IBM Selectric typewriter, introduced in 1961 and ubiquitous in offices by the mid-1960s, gave technical writers their first significant productivity tool: the ball-element design allowed rapid font changes, and the Magnetic Tape Selectric Typewriter (MT/ST, 1964) let writers record keystrokes for revision and reprint. Phototypesetting equipment gave large documentation departments the ability to produce camera-ready copy without a commercial print shop. The improvement in production quality raised professional standards: by 1970, a well-resourced technical documentation department could produce manuals indistinguishable from commercially typeset publications. The Society for Technical Communication, renamed in 1971, began hosting annual conferences where production standards and language conventions were professionalized across the field.

  Effect on the work

  The Selectric era modestly increased productivity but did not fundamentally change the labor structure of documentation: each writer was still responsible for a single document stream. The major labor shift was the separation of "writer" from "typist" that the Selectric enabled -- technical writers could now type their own drafts rather than dictating to a separate typing pool, which collapsed a two-person workflow into one.

• Desktop publishing1985–1995

  Desktop publishing: PageMaker (1985) and FrameMaker (late 1980s)

  Aldus PageMaker, introduced in July 1985 by Paul Brainerd for the Apple Macintosh, was the first widely-used WYSIWYG page layout program for personal computers. Brainerd coined the term "desktop publishing" to market it. For technical writers, PageMaker and its successor FrameMaker (developed by Frame Technology Corporation, designed specifically for large-format technical reference manuals) collapsed the production workflow that had previously required a typist, a layout artist, and a print-shop relationship into a single workstation. FrameMaker's strength was handling extremely long, structured documents: tables of contents, indexes, cross-references, and conditional publishing for multiple product variants. Adobe acquired FrameMaker in 1995 and explicitly repositioned it as a tool for technical writers, where it remained the dominant professional platform through the 2000s. Desktop publishing transformed what the profession was: technical writers now controlled the entire document from first keystroke to print-ready output.

  Effect on the work

  Desktop publishing reduced the number of specialists required to produce a documentation set. Layout artists and production coordinators who had been part of large documentation departments became redundant. Simultaneously, the personal computer industry's explosion in the mid-to-late 1980s created enormous demand for user documentation: every software product and peripheral device shipped with a manual. The net employment effect was strongly positive through the late 1980s despite the productivity gain from desktop publishing.

• Web1995–2005

  Web and online help (HTML help, RoboHelp, WinHelp -- internet era documentation)

  When Mosaic (1993) and then Netscape (1994) made the web accessible to non-technical users, the documentation industry faced its first existential rethinking. Printed manuals became obsolete almost overnight for software products: by the mid-to-late 1990s, online help systems accessed through a product's Help menu replaced the printed manual as the primary documentation format. Microsoft WinHelp, Robohelp, and HTML-based help systems required technical writers to learn new tools, to think about documentation as a navigable hyperlinked system rather than a linear document, and to write for a different reading pattern (scanning and searching rather than reading cover-to-cover). The internet boom of 1995-2000 also created an enormous new market for documentation: every new website, SaaS product, and e-commerce platform needed user documentation. The demand surge of this period is why the profession's estimated headcount roughly tripled between 1980 and 2000.

  Effect on the work

  The transition to online documentation compressed print-production roles further (no more print-ready output, no more mailing room) while simultaneously expanding demand for writers who could produce hyperlinked, search-optimized content. The dot-com bust of 2001-2002 hit the documentation profession hard: hundreds of contract technical writing positions at startups and software companies were eliminated. Headcount contracted noticeably from the 1999-2000 peak before recovering through the mid-2000s.

• Structured authoring2005–2015

  Structured authoring: DITA XML (IBM 2001, OASIS standard 2005) and component content management

  Darwin Information Typing Architecture (DITA), developed inside IBM starting in 2001 to replace its unwieldy IBMDoc format, was donated to OASIS and published as an open standard in 2005. DITA formalized what experienced technical writers had been doing informally: treating documentation as modular, reusable components (topics) that could be assembled into different publications for different audiences, locales, and product variants. A single "warning" topic could appear in 40 different manuals without being written 40 times. For regulated industries, aerospace, and medical devices, DITA became the professional standard. The tool ecosystem around DITA -- Heretto (formerly easyDITA), Oxygen XML Editor, Arbortext -- created a new specialization: the structured author who understood both the writing craft and the XML schema. The CCMS (component content management system) era coincided with globalization: multinational companies could manage a single English master and route it through translation management systems, compressing localization cost dramatically.

  Effect on the work

  DITA and structured authoring increased per-writer throughput significantly for large documentation programs, reducing the labor required per page of output for routine update cycles. However, the specialized skill required to work in DITA systems created a premium segment of the profession: DITA-proficient writers in regulated industries commanded materially higher salaries and were more insulated from the employment volatility affecting consumer-software documentation writers.

• Docs-as-Code2014–2023

  Docs-as-Code: Markdown, Git, static site generators (Sphinx, MkDocs, Docusaurus)

  The Docs-as-Code movement -- treating documentation with the same version-control, peer-review, and continuous-integration practices used for software code -- emerged organically at large software companies (Google, Stripe, Twilio, Cloudflare) in the early 2010s and became widely practiced by the mid-2010s. Write the Docs, a community conference first held in 2013, formalized the practice and vocabulary. Technical writers working in the Docs-as-Code model authored in Markdown or reStructuredText, committed changes via Git pull requests, ran automated tests (link checking, prose linting via Vale) in CI pipelines, and published to static site generators like Sphinx, MkDocs, or Docusaurus. The "Documentation Engineer" title emerged at companies where the writer was embedded in an engineering team and contributed to the codebase itself. Salaries in this tier of the profession ($110-135k at companies like Stripe and Cloudflare as of 2024) reflected the cross-domain skill premium. Docs-as-Code was also the technical foundation that made AI-assisted documentation possible: when documentation lives in Git, an AI model trained on the codebase can produce plausible first drafts.

  Effect on the work

  Docs-as-Code created a strong bifurcation in the profession: writers who mastered the toolchain commanded premium salaries and stable employment, while writers who remained in legacy tools (Word, older CMS platforms) faced increasing competition from AI automation of their specific workflow. The overall employment count remained roughly flat through this period, reflecting the two trends offsetting each other.

• AI-assisted documentation2022–present

  AI-assisted documentation: Mintlify, GitHub Copilot Docs, Scribe, ChatGPT/Claude for first drafts

  ChatGPT's public launch in November 2022 put AI-assisted writing tools in the hands of every technical writer overnight. Within months, documentation-specific AI products proliferated: Mintlify (which generates and maintains developer documentation from code context), GitHub Copilot's documentation generation from code annotations, Scribe (auto-generates step-by-step procedure docs from screen recordings in under 60 seconds), and Tango (auto-captures UI workflows as annotated walkthroughs). The effect on the profession was bifurcated from the start. Routine documentation -- software procedure guides, FAQ articles, basic API reference content, in-app microcopy -- became largely automatable, and companies with mature Docs-as-Code pipelines found they could maintain documentation sets with significantly fewer writers. The work that remained robustly human was the work AI tools cannot safely do without institutional knowledge: SME interviews, information architecture decisions, regulatory accuracy validation, and the craft judgment that distinguishes documentation that actually helps users from documentation that merely describes a product. The BLS projection of approximately +1% employment growth through 2034 (from 56,400 to an estimated 56,900) reflects the view that AI productivity gains will offset expansion demand -- net flat.

  Effect on the work

  BLS projects +0.9% employment growth for technical writers 2024-2034, approximately +500 positions over the decade, against a roughly +3% all-occupations average. The profession is expected to see about 4,500 annual openings driven primarily by replacement need (retirements, career transitions) rather than net new positions. The sector-level distribution is shifting: information and professional services are projected to grow (developers need more documentation as software proliferates) while manufacturing declines.

What's changing in your day

Three parts of your work where AI is already doing real lifting, and what stays yours.