I recently received an email from a reader who asked to know what the job of a technical writer is like. Anoop writes,

I am a computer science Master's student at the University of British Columbia, Vancouver. I am in my second year and I am on the lookout for jobs. Other than the system software engineer posts, I am considering applying for a job as a technical writer too. I do love witing as much or maybe more than I love coding and understanding operating systems. I do have experience in system software but not in technical writing, though I do blog occasionally and I also have written a few technical how-tos.

Could you please tell me what the job of a technical writer is like? How different is it from that of a software engineer? I know it pays less, but I guess you might get more satisfaction especially if you like writing? Could you, if you have the time, tell me how a day at work goes like? Do you think with my limited experience, I have a shot as a technical writer and in the area that I'm interested in?

I love getting questions like this. Of course technical writing isn't creative writing, but it does require a lot of writing skills. If you can organize complex topics and communicate concepts clearly and concisely, conforming to a specific style, you probably have most of the writing skills you need.

As far as the salary and economic outlook, technical writing was listed as the 13th best job in America, according to Money Magazine. Technical writers earn an average salary of $57k per year. Software engineers, in contrast, appear at the top of the list and have an average salary of $80k. The job growth for engineers is projected at 46%, while that of technical writers is 23%.

In short, the economic outlook for the field of technical writing is good. As long as the tech industry is hot, the demand for technical writers will be there. Almost every software project needs a technical writer.

A lot of your job as a technical writer involves figuring out what the engineer is building. If you have an engineering background, you're often a step ahead of other technical writers. If you can read programming code, your potential for higher income increases significantly.

The questions you asked can be answered in a lot of different ways, so I'll give you a sample of my typical day. Below is more like a composite of different tasks all done within several weeks.

Tom's Typical Day as a Technical Writer

• Ride metro to work -- listen to podcasts on technology topics. (Tech Writer Vocies and DMN Communications are great podcasts to listen to for technical communication.)
• Attend morning scrum meeting, where each team member reports on what they did the day before. Try to figure out what has changed in the app., what new features or functionality have been added or are planned.
• Return to desk and explore the application. With development environment access, the app is only partly-functional. Have to fill in the gaps of how it could work. Experiment, test, click here and there. Guess, test out hypotheses, isolate, observe, etc.
• Visit software engineers to ask questions about application functionality. Inquire about workflow and other procedures.
• Visit business analyst to ask about user characteristics and tasks. What tasks will users want to perform? Try to determine who users are, clarify the different roles, and their familiarity with the concepts.
• Return to desk and validate online help file by meticulously going over the steps to confirm the accuracy.
• Create show-me demos using Captivate that provide audiovisual tutorials for the most common tasks. Getting the timing right for the slides is painstaking, but the end product is appealing.
• Create Visio diagrams representing workflows and other processes in the application. Submit to project manager for review.
• Create one-page quick reference guides in Adobe Indesign for each user role. Meticulously confirm accuracy of the steps.
• Discover new functionality in software app that wasn't told to me. Have to return to the documentation and update it.
• Attend meeting about project, listen to engineers and project managers and business analysts talk for a while. Ask when they're going to code the help button. Realize that the project is going to be delayed several weeks.
• Tackle bug with RoboHelp online help output. Display in Firefox needs a style adjustment. Tweak css for a while.
• Access project sites to see if any technical documentation is relevant to me (and up-to-date). Skim through requirements. Find discrepancies between requirements and development environment. Ask project manager which is right.
• Add more topics to online help based on new features and functionality discovered in the app.
• Suggest to engineers that they change some of the on-screen text and make the buttons behave more predictably.
• Print out documentation for the business analyst to review, and set up a meeting to encourage him to review it.
• Write article on new features for release notes and corporate newsletter. Pitch idea of a product blog.
• Return to metro for home -- put on headphones and listen to podcasts.

That's sort of a typical day/week/month/life of a technical writer.

Vancouver happens to be a hub of tech writing. Last year I gave a presentation titled "20 Usability Tips for Blogging" at Doc Train West (held in downtown Vancouver). This year I'm going to be on a blogging panel with several distinguished bloggers. If you can make it, (May 6-9), I highly recommend that you attend the Doc Train West 2008 conference.

Is technical writing satisfying? In a way, yes. I previously worked as a marketing copywriter. Sometimes I had a hard time feeling good about what I was writing, because I myself didn't buy the products. I know technical writing helps people. Today I received an email from someone who mentioned they used the help and now they understand a difficult concept in the app. That felt good. With all the people out there who are confused by technology, who feel frustrated and try to find answers online or in help files, it feels satisfying to know I'm engaged in trying to help them.

Through my examples above, I tried to show that technical writers do a lot more than writing. Very little time in the day is taken up by pure writing. There's a lot of design, discovery, visuals and other tasks that writers do. My blog is actually what cures my itch to write.

You've probably wondered if technical writing is boring. I wrote a post on this a while back and received some great feedback. I think the key is to keep yourself engaged in the field. Writing a blog and creating podcasts make me enthusiastic about technical communication more than anything else.

Specifically, listening to podcasts can give you ideas, help you see how others have approached problems, and expand your knowledge in numerous ways. Unlike blog posts, you can often feel people's excitement and energy through their voices.

Special Request: I'd like readers of this Elephant blog to describe a day in their lives as technical writers. Not only for Anoop, but for me as well. How does my day compare with yours? Is technical writing in the U.S. highly similar to that in Israel? Looking forward to hearing from you.

Do you like this post? If so, subscribe to my blog's RSS feed.