Pros: Plenty of information clearly presented; information I wasn’t expecting
Cons: Too much cheerleading
Rating: 4.5 out of 5
First posted 2/9/2005
Review book courtesy of Alpha Books.
When you do say “yes,” be sure to be clear about what you’re saying “yes” to. … If the marketing department wants the moon, make sure they understand that you’re saying “yes” to an orbiting satellite, not a planetary body. … Also be sure to follow up your “yes” with a written memo that spells out exactly what you’ve said it to.
The “Complete Idiot’s Guide to Technical Writing,” by Krista Van Laan and Catherine Julian, is aimed at people who want to go into the field of technical writing but aren’t sure where or how to start. It contains a great deal of information that would also be useful to those who’ve ended up in the field and haven’t found their feet yet, or who have trouble in one job area or another. You’ll find plenty of very specific information in here on problems and challenges tech writers face and how to solve them.
On the job
This book was published in 2001, and some of its information is bound to be out of date. It’s a little too bad that the authors put so much effort into cheerleading the state of the market for tech writers given that tech companies aren’t doing quite so well any more.The authors are also a little blindly optimistic in their “anyone can do it!” attitude–they seem to take it as a given that anyone who’s interested enough to pick up their book already has the basic skills necessary to do the job, and I don’t think that’s a great assumption. (Attitude is important, but realistic assessment helps too.)
That said, there’s a lot of excellent information in here on finding, learning, understanding, and keeping a job as a technical writer. There’s information on typical tasks associated with tech writer jobs, attributes common to good tech writers, breaking into the field (samples, writing tests, portfolios, degrees, recruiters, interview tips, networking), and the characteristics of a good technical document. The book goes into usability issues, completeness, consistency, and more. It guides you through five steps to creating a technical document, and introduces you to the idea that a lot of your time won’t be spent writing at all–it’ll be spent talking to people, using the products you’re writing about, collecting information, revising, and so on. It discusses the differences between working on a document that you’ve authored and one that you’ve “adopted” from someone else.
This book puts a great emphasis on communicating with others–much more so than I was expecting. The authors point out that it’s often the tech writer who ends up acting as a go-between for the engineers and other departments. It’s the tech writer who has to get information out of everyone about deadlines, program features, and more. It’s the tech writer who has to know how to gracefully encourage and handle feedback on her drafts and shepherd people into giving her that feedback on schedule. The tech writer’s job can require a surprising amount of tact and people skill.
The authors spend a fair amount of time detailing the ways in which this can impact your job and work. Better than that, they give you plenty of instructions for handling it. Tactful ways to persistently work on getting information; ways to handle difficult people who don’t give you what you need; conveying the proper level of expectations for the various drafts you’re working on… if it has to do with communication between you and someone you work with, for, or near, it’s probably in here.
Scheduling and deadlines
I’ve known a number of software engineers at a variety of companies, and I know one of the biggest issues on any project is scheduling. Estimating a schedule is a lot harder than it sounds. While the authors are very up-front about the fact that you simply can’t know how long something will take you without a lot of experience under your belt (and even then it can be a gamble), they do give you guidelines and even a formula for typical times that can help you at least be in the right ballpark. Hey, it may not work out perfectly, but it’s a lot better than saying “uh, one month,” when it’s going to take you a year to do something. There are also plenty of hints to help you meet your deadlines.
Elements of English, document preparation, and tools of the trade
This book includes information on elements of English language usage that will make your documents clearer and easier to understand. A user’s manual must convey different information in different ways than, say, an academic treatise, a novel, or a pamphlet does. You’ll find information on indexing, active vs. passive voice, punctuation, humor, paragraph length, tense, person, figures and tables, and “simplified English.” Much of the information here would be helpful to nonfiction writers of all kinds, not just tech writers.
The book also spends some time on document layout issues and graphic design, both of which are tasks that can end up in a tech writer’s job description. I think perhaps a bit much time was spent on computer tools; such information can become out-of-date easily, and the space might better have been spent directing the reader to places where they can find out the current state of affairs. At least the authors did try to stick to information they had some confidence in, however.
Working from home
There’s also information in here on telecommuting and working from home. Once again the authors’ enthusiasm dates the book a little. They make great claims for the willingness of employers to allow their people to work from inexpensive home offices, but my understanding is that things haven’t worked out that way. Too many companies found that people just didn’t work well from home; I gather it’s gotten harder to convince a company to allow you to telecommute nowadays.
However, on the flip side, there’s a lot of great information in here on getting the most out of working from home. If you’re one of those many people who just don’t work as well without someone standing there cracking the whip, this book might help. It contains suggestions to help you with discipline issues, keeping in touch with your co-workers, and so on.
My only negatives regarding this book stem from a semi-blind optimism on the part of the authors; they seem to think the positive state of things like the market for tech writers will last for the foreseeable future. I think a few too many of their assumptions were overly hopeful, and because of this an unwary reader could get a skewed perspective of the job. However, I think the advice in areas such as document design, discipline, job skills, people-management and so on more than makes up for these flaws. This is a valuable resource for someone interested in entering the field as a technical writer.