Technical Writer

This is a suggested alternative to programming for those suffering from Programmer BurnOut (see AlternativeJobsForProgrammers).

As a TechnicalWriter myself, and one who migrated from programming, I think it's important to note a few things about the field:

You need to be able to write. Well.
You need to know programming. Well.

This sounds obvious, but the one complaint I've heard more than any other from those trying to hire tech writers is that they're either not familiar enough with technology, or they can't write well. If you know the technology but don't have a lot of writing experience, be aware that it takes awhile to develop the skill of writing really good documentation.

Also, technical writers tend to be involved in a larger portion of the system than an average developer. You'll be ready to keep a large-scale view of the system in your head, and be able to dive into any part at any time ("Hey, the Gantt Chart works! Send it to documentation!").

Documenters generally don't get much feedback from development. It's hard to keep track of what's changed, which makes it difficult to keep the documentation up-to-date ("The Gantt Chart colors changed! When did that happen?" "Oh yeah, didn't anyone tell you?"). It's worthwhile to be aware of this and take appropriate precautions (latch onto a few developers, be very clear with management about responsibilities, establish notification processes, etc.).

That said, I find it's a very fun job. -- BrentNewhall

So, as someone migrating the other way, that is a decent writer who is a bit backward about programming, do you think there's hope for me? Is it conceivable that I could manage to educate myself sufficiently about the technology to become a good TechnicalWriter? Which, if either, is easier, taking someone who can write code and teaching them to write, or taking someone who can write and teaching them about code? And as an observation, I've noticed that those who write code, and those who write words, for the lack of a better way of describing it, are more similar than one might think in the way they think and how they prefer to work.-- DanielleOviatt

Notes from a programmer who tried it

In 1995, I got burnt out on programming and took a job as a technical writer. In programming, I always enjoyed making complicated things simple and easy to understand, and I've always enjoyed writing and language, so technical writing seemed like a good thing to try. I enjoyed it for a while and learned how to write some really lucid prose, but at some point it got boring and I came to feel that my economic position was weak. The reason is that most of the stuff they pay you to write is simple, step-by-step instructions, usually instructions for operating screens in software. Most of the time, this kind of technical writing is unnecessary, for it's obvious from looking at the screen how to use it. "In the Customer Name field, enter the customer's name." You're writing this stuff only because some clueless ISO 9000-style organization has decreed that all software shall have a UserManual as a measurable aspect of quality, not because it serves any real purpose. Because this stuff is borderline useless, you have a weak bargaining position.

There's a major exception to all this: writing ApplicationProgrammingInterface manuals. If you're a programmer who wants to try technical writing, writing API manuals lets you continue to use your programming knowledge, it pays well, and it's actually important stuff to write. People actually read your stuff and use it. A good API manual can save people days of frustration as well as serious bugs in the released product. And not many people can document APIs well. It takes a combination of programming knowledge, empathy, and skill with language.

Also, there are unique technical-writing jobs here and there that are really interesting. Writing up how to use specialized hardware can be interesting. You have to figure out the mental world a person has to be in to use the hardware correctly and get it across in a page or so (e.g., what's an azimuth?). You have to pull this out of subject-matter experts who are often terrible at explaining things themselves. This kind of documentation has real ReturnOnInvestment and few people can do it well.

I went back to programming and thoroughly enjoyed it again. I still get to indulge my love of writing when a tutorial really needs to be written or when (in marketing mode) we need to send our message to the world in simplified terms. SpecializationIsForInsects.

-- BenKovitz