I’d Rather Be Writing - Tom Johnson

“Could you please tell me what the job of a technical writer is like?”By Tom Create show-me demos using Captivate that provide audiovisual tutorials for the most confusing tasks. Getting the timing right for the slides is painstaking, but the end product is appealing. Create Visio diagrams representing workflows

Here’s an alternate take that gets less visibility in online forums or anywhere else.

I document application-specific operating systems and love it. Run ps -aux on a *nix box and imagine having to follow what each process does, the interplay between these processes, and repercussions for the user and application. Then you have to describe this stuff. Not to mention what goes on, on the embedded level and even lower. I think it’s awesome work, but you won’t hear much about it.

Generally I don’t get to use rich AV applications or create non-paper/pdf documents. I could just as easily write a hundred page .txt file and hand it off to a DTP/Web design geek and let him or her take care of layout and formatting. Sometimes the visual stuff is engaging, but I’d rather not dwell on it.

–
Someone with a masters in CS has the ability to add profound value to documentation. However, I think you will be hard pressed to find a project/organization that believes in realizing this. OTOH, something like API documentation is crucial, and the docs can often sell the language.

Great post, Tom. I posted about this same topic about a year ago, so here is what I wrote in that post:

So, typical day: in the AM, start the day by opening your team’s dashboard. The dashboard is usually a software program that you look at that has different tasks each technical writer will perform and the statuses of each. For example, you might be working on a project and the programmer has add a feature where the user can click a new button on a dialog box; the “task” for the technical writer is to add information about the button to the existing online help (online Help being defined as the information that appears in most software programs when you click the Help menu and then select Help Contents). During my morning orientation, I usually like about 5 minutes to skim all tasks assigned to me in the dashboard, being careful to note each one’s status. Each task flows through the same path of statuses: New -> Writing -> Substantive Edit -> Writing -> Technical Review -> Writing -> Copyedit -> Production -> Test -> Complete. After orienting myself, I also check my calendar to see what’s on tap for the day and rest of the week; if there is a meeting, I make preparing for it a top priority. After orienting myself and then mentally prioritizing the tasks, I complete the task with the highest priority.
The highest priority task is usually writing about a feature that will be announced to users in the upcoming Release Announcement. To write about the feature, I first research the feature. The research involves reading the Specifications document from the Development group (and any other additional verbiage the Developers or submitter of the feature wrote about it), opening my Beta software and testing the feature’s functionality myself, picturing myself as the user trying to accomplish this goal, analyzing the existing online help to see where this feature fits in, opening my team’s Word template to outline a draft, and then write the draft (whether it be completely new topics or minor changes to existing topics, in which case I just highlight my changes so that the editor, technical reviewer, and peer-tester can quickly tell what I’m proposing as the new content).

Then, in the PM, I continue from where I left off in the morning, sometimes that means working on the same task item as in the morning, but usually it means switching to a different task item that still needs to be completed, as indicated by the status in the Doc Team’s dashboard (queue of tasks).
In addition to the standard days of moving various tasks to different statuses in a task queue, technical writers also perform a wide variety of other tasks. Here are a few that I perform at least monthly: offer usability tips to the programmer or manager (anything from improving a label to suggesting a completely different user interface design), attend a meeting to discuss new features with a cross-functional team, analyze the entire suite of online help and come up with ways to improve it, read logs of support calls to see where users are getting tripped up and then create new tasks in the task queue to enhance the online help in those areas, read Spec documents to prepare for meetings, perform general tasks required by the HR or IT department to keep up-to-date with their policies, write embedded Help (small sentences that display in the software application itself), write and edit Wizard text, enter a bug or enhancement request into the bug-reporting system, peer edit and peer test fellow Doc Team member’s feature, and many other various tasks. Over the next year on this blog, I’ll try to add to this list of “other tasks” that I do outside of the standard queue tasks.
To close, if you are a student and can take a critical thinking class, I highly encourage you do so. The skill that I use most often in my job is critical thinking. Nearly everyday, the majority of my time is spent asking myself questions; most of the questions are focused on the user to try and question myself continually about what they need to do and what information they need, and when/where do they need that information. For example, I’m asking: What words can I choose to help the user the most right here? Where can I put this topic so that it will be helpful when the user needs it? Is this task intuitive for the user? If not, what can I suggest to the Dev team to help make it more intuitive? Would F1 Help about a specific field be best for this information or would it be better in an overview, procedure, or video? Better in an existing procedure or better in a new procedure? What will be most confusing to a user about this process? Can we redesign the software to make it less confusing, can I add an example in the online help to make it less confusing? And on and on. Questioning, all day, everyday. Questioning to try and anticipate user questions so that I can provide answers to those anticipated questions. Critical thinking, all day, everyday.
One last thing, to be sure that I’m able to make good suggestions to improve the application or online help, I constantly try to keep abreast of the technical communication field. Each month, I try to attend both a SIGCHI (Special Interest Group for Computer-Human Interaction) chapter meeting and an STC (Society for Technical Communication) local community meeting.

Original post URL:
http://heidilhansen.blogspot.com/2006/12/day-in-life-of-technical-writer-buffet.html

[...] I’d Rather Be Writing blogger wrote a great article about a typical day as a technical writer. I was going to blog about [...]

Hi, my name is Ryan. I work as a technical writer for National Instruments in Austin, TX. We’ve put together a web site that shows what a typical technical writer’s week is like, at least at our company.

Here’s the URL: http://www.weekinthelife.net

Ryan, thanks for adding the link about the technical writer’s typical week. I like the site you created. It does look like they’re all having fun.

[...] “Could you please tell me what the job of a technical writer is like?” [...]

[...] It’s your lucky day. I’ve already wrote an incredibly detailed post about this here: “Could you please tell me what the job of a technical writer is like?” [...]

[...] day as a technical writer. I was writing about another blogger/technical writer I read about and his typical day. But since then, my post always shows up on the first page result when googling “technical [...]

I updated my post with a direct link to your post. Thanks for letting me know about it.

[...] day as a technical writer. I was writing about another blogger/technical writer I read about and his typical day. But since then, my post always shows up on the first page result when googling “technical [...]

[...] day as a technical writer. I’ve read about the typical day of a technical writer from the U.S., Australia, the U.K., and . . . China (me)! Despite the fact that we live in different parts of the [...]