Technical Writing Vs. Narrative Fiction, Part 1

I work as a technical writer for a software company. I spend way more time per week writing technical documentation than I do writing fiction or coming up with blog posts. When I tell most people I’m a technical writer, they look at me quizzically, canting their head like a dog agitated by a high pitch. I explain that a tech writer creates technical documents like software user’s guides, installation guides, and online help. The general public uses this type of documentation all the time. Whenever you are on your PC or laptop using a program (such as Microsoft Word) and click that Help icon, the help system and all the accompanying topics that display were written (hopefully) by a tech writer.

After juggling both technical writing and narrative fiction, I’ve found that there are some similarities between the two types of writing. Especially after being asked questions like, “Does the tech writing take away from the novels?” or “Is it hard to switch gears between the two?” The two types are different for lots of reasons, but that doesn’t mean that a strength used in technical writing can’t cross over and be used in a novel. And vice versa.

Starting with this post (and running for the next two or three) I’ll compare and contrast elements of both technical writing and narrative prose, highlighting where they overlap. Elements include:

- Planning
- Research
- Telling a story
- Editing
- Structure
- Consistency
- Technical and Peer Reviews

I’ll conclude by discussing whether technical writing is a good career for a fiction writer and ask questions to help you figure out if you would make a good technical writer.

Let’s take a look, shall we?

Planning
Tech writing is all about the planning. It works like this: the release schedule of a software product (for example, software that monitors your network and lets you know when connections are failing) is generally very short. Maybe a year. More if you're lucky. That means, as a writer, you have to figure out how to write about a new feature that is part of the software release.

In other words, let’s say this network monitoring software will now have the functionality to work even when there is a physical on-site disaster (for example, an earthquake or hurricane). This new feature is called disaster recovery. I have to monitor the progress of this feature’s development, learn about it, determine who the audience is (who the users are), and then, when development has finished writing the code (you know, C ++ or Java or whatever those guys do) use it to make sure it works like they tell me it's supposed to. Before I start writing, I have to figure out what needs to be documented and, sometimes, how long it will take. In most cases I’ll write an outline, sort of like a table of contents that will highlight what I plan to cover in each chapter.

I talk a lot about outlines on this blog. I’m no stranger to outlines for either tech writing or for novels. I worked on novel outlines before I became a tech writer, but I think my novel outlines have benefited from having to outline and plan all my technical documentation. I feel I now better determine what scenes must go in my novel to move the story along, what scenes I could write but would probably get cut later, which scenes are necessary to include to understand character motivation, and (if I choose to include them in the outline), which scenes end the story.

Before I start writing a novel, I often write a truncated outline so I can figure out the best way to start the book to lead me in the right direction to tell the story I want. I may have no idea what will happen in later scenes, even though I can picture some overarching idea about how the story ends and how to get there. With technical documentation, you have to map out all parts of the document before you start writing, to ensure you are telling the right story for the right user (more about telling a story later). Planning is an aptitude that serves me whether writing on the job or off.

Research
It doesn’t matter if your novel takes place in a small Florida town and you want to know what the local sheriff does all day or you're writing about a graphical user interface—you need to do some research after you decide what subject to write about.

You can start your research online. Yes, I Google and Wikipedia at work. You have to be careful, but public search engines and wikis are not a bad place to start. Of course, nothing compares to interviewing a subject matter expert. Or getting firsthand experience. Or both.

Go to Florida. Go to that small town you saw on Google street view. Interview that sheriff. Walk around that small town. I guarantee you’ll garner much more data than you thought was there in the first place. Firsthand experience is imperative. If you can't get firsthand experience with a subject, then talk to somebody who can.

As a tech writer, when I’m faced with writing about a feature or technology I know nothing about, I try to do as much research online as I can. That means seeing if there is generally available information about the topic. Yes, disaster recovery is a recognized industry term. I can find overviews and learn concepts very quickly. Then I go to my company’s internal online resources. This may include an intranet or wiki page where the engineers I work with have posted information about the technology and, hopefully, detailed information about how they are implementing the feature/technology with our product. From this information I start really solidifying the outline/Table of Contents.

After I understand, more or less, what’s going on, I sit down with a subject matter expert (my sheriff) and ask informed questions. I need to know enough to understand at least some of what my subject matter expert tells me. Same goes for interviewing somebody for a novel. You should know going in what questions you want to ask, at least enough to get the conversation going into the direction you hope it takes. You should come away with lots of notes or a full audio tape, and ideas about how to make your story or documentation better. And don't forget to thank the sheriff, and make sure it's okay to contact him later to ask follow-up questions.

Next time: Telling a Story