| Apple and Cisco are two examples of companies with large, well-organized technical documentation teams. I've worked on both teams. There are certainly many other examples. I've also worked for a few startups on setting up their technical documentation processes. My career in software started January 1, 1988 at Apple. Roughly 1/3 of my career has been as a technical writer, and 2/3 as a programmer. The two disciplines require comparable levels of knowledge and technical skills, but programming generally gets much better funding and other support. There are several reasons for that. The most obvious is that you can't ship a software product without some programming, but you can ship one without any technical writing. It's generally a bad idea, but it's possible. Another reason is that technical documentation is in almost all cases a pure cost center. You don't make money from your technical docs. Worse, you can always make docs better with more effort, so there's no theoretical ceiling on its cost. How expensive are docs? Well, how much have you got? Yet another reason that docs get short shrift is that smart people tend to assume that they can write. They are often mistaken. Among professional tech writers and editors, "engineering documentation" is a pejorative phrase. Nobody thinks that they can write good software with no experience and no training, but many otherwise intelligent people make exactly that assumption about tech docs. Also, it must be said that technical documentation is probably the least cool job in software, even less cool than compatibility testing. Nobody ever called a tech writer a "rock star" (although I can think of a couple that probably qualify). I haven't seen a lot of hiring posts for tech writers on HN, either, but that doesn't surprise me. HN is sort of startup-oriented, and it usually takes startups a while to realize that they need professional tech writers. It happens when someone realizes that they're spending too much supporting customers and partners because they're not spending enough on docs. That's when they go shopping around for someone to help them fix that problem. I've been that guy before, and I also know a good recruiter who specializes in that, in case anyone needs a contact. |
Not here. It's documentation written by and for a different audience, and it's valuable. As a professional technical writer and editor, I vastly prefer it over having engineers who won't write anything.
Tech writer value comes from adapting engineering docs for other audiences and use cases: identifying what context needs to be there (or doesn't), providing the value prop, demonstrating real-world workflows, presenting it in a broader narrative of productive usage, and finding ways to make it all confirmable and maintainable over time.
But we aren't (often) engineers, and we need those engineer-written docs as a starting point for our own understanding. I'd avoid ever being pejorative about that. The problem's usually with a culture — or leadership — that believes engineer-written docs are enough for non-engineering users, and that all any tech writer should do is proofread and publish them.