When people ask me, "what do you do [professionally]?" I always seize up, and I never know how to respond. Sure "technical writer" is one of those careers that you see in high school career aptitude tests (right?) but its not terribly understood.
The worst thing is that there are a bunch of different technical writing sub-fields that didn't overlap. So if you know another technical writer, the chances are they do something closer to documenting business practices for banks (or scientific equipment! or cheese extruders!) and don't really do anything like what I do.
I'm sometimes tempted to say "I'm a software engineer" or "I make software," which is true, but I feel like it's disingenuous. Sure I write code sometimes, but I'm not exactly writing software that's running on hundreds of thousands of systems (like my coworkers who "real engineers.")
Maybe it's just impostor syndrome. So be it.
The second hard part is that I don't actually write that much, by volume.
The hard part of technical writing isn't constructing English sentences. That's the easy and fun part. As a result, any given day is mostly filled with other things. For all of you that wonder what kinds of things a technical writer working in software development is worrying about at any given moment, here's a list:
If software isn't improving or changing, it's not being used. Depending on products, releases happen at least once a year and sometimes as much as six months a year. If release isn't continuous. I spend some portion of my week figuring out what new features are and balancing those new features against other features and release dates to figure out when and how we should document them.
In some sense software development is all about considering context, and figuring out how to properly handle deeply nested situations. This makes great programmers great. It also makes great programmers terrible at documentation. Furthermore it makes programmers really poor designers of things that users interact with. Even when the users are other programmers.
But it means that I end up spending some amount of time working with programmers saying, "why is this a noun, and all the other options like it are adjectives?" or "isn't this option structurally similar to this other option that someone else wrote last year?"
There's really no good reason to publish changes documentation infrequently. If you know about bugs (typos, correction, unclear patches etc.) in the existing documentation it makes sense to go ahead and fix them, and get those out in front of users. And while you can make the publishing process automated to some extent, there's work associated with planning, testing, and running deployments.
At the beginning of the year I said to a coworker, "I think that most of the hard problems in documentation projects are really build engineering problems," and I spend some amount of time making sure that the build system is faster (so that the we can spend less time testing changes,) and that the build system automates common tasks (so that we spend less time mindlessly manipulating text.)
I read a lot of proposed changes, make comments for style, accuracy, organization, and so forth. This also involves some amount of direct editing and rewriting of exiting content.
Documentation has a weird stabilization curve, and as a result, even after a release "stabalizes" it takes time for the documentation to calm down. Things like "we forgot to tell you about this feature," or "actually upgrades require an extra step," or "people should be careful when using this feature."
And like software there are other bugs that don't get caught in the review process. Or bugs in the software that the documentation needs to reflect. Or pieces of text of text became confusing because of changes, etc.
Managing organizational drift.
While most documentation work is only a few hundred words, the experience of documentation is much larger in scope, and I end spending part of my time making sure that the macro-organization makes sense: file names are idiomatic, that chapters have parallel structure, that the navigational tools correctly direct readers "correctly."
So that's what I do. Make more sense now?
