[I posted the following review of James Gill’s How to Get Started as a Technical Writer over at Amazon today. I know a few technical writers follow this blog, so give me your take on the content of the book.]
I hate sock-puppet reviews as much as the next person–i.e., friends who write glowing reviews in return for them. So let me say something about how I got this book. I don’t know James Gill professionally or personally, but we do frequent the same indie writers’ haunts on the web and I’ve posed some techie questions on his blog. When I heard he wrote a book on technical writing, I suggested (in a roundabout way) that I’d write a review for a complimentary copy. I don’t know if it was courage or craziness on his part, because he should know by now (we’ve butted heads a few times too) that I’d tear apart my own mother’s book if I didn’t like it. But he obliged and so here’s my review.
I should mention, too, that I’m an academic by training but (mostly) a technical and science editor by profession, so our fields do overlap.
1. Who is this book for?
Read the title. This is a book on how to become a technical writer. It’s not a manual or handbook for practicing technical writers. If you want to learn the mechanics of technical writing, you’ll need books like the Chicago Manual of Style, The Handbook of Technical Writing and some of the other staples of the writing and publishing trade. But if you want to get a job as a technical writer, this is your book.
2. So is the how-to advice any good?
In a word, yes. Too many career advice gurus and resume tipsters give you guidelines that are too abstract. You need precise, step-by-step advice on what to do to for a specific job, especially for one like technical writing that’s hard to pin down: What should be in my resume? What sort of software should I be familiar with? How do I pitch my skills? How do I even get a foot in the door? And just as important: What can I ignore?
I can tell you from experience that Gill’s advice is concrete and useful. I even had a few of those painful moments of recognition when I read about what not to do. Anyway, a few examples. Gill suggests something I hadn’t thought of: volunteering as a technical writer for an open source software project. This struck me as excellent idea for an undergraduate who wants some experience, but who really doesn’t have the time to find or do a real technical writing job. He also gives good advice about creating a portfolio. Any old job advice website will tell you to create a portfolio (which means what, exactly?). But Gill gives some concrete and creative ways of building one that will showcase your talents when you don’t have the experience to draw upon.
But what may be his best advice is something I know from experience: be a solution to a problem. In other words, when you write up your resume and go for a job interview, try to position yourself as the solution to the problem–more than that, be the solution. After all, that’s what firms look for when hiring technical writers, especially on contract. They don’t want chair-fillers who churn out lumpy copy when they’re in the mood, and they don’t want people who need hand holding; they want people to fix their problem efficiently, whether it’s technical documentation, on-line help, whatever.
3. How’s the writing?
It would be bad if a technical writer couldn’t write a technical introduction to technical writing wouldn’t it? Not to worry. The book is written in that colloquial and “user-friendly” style that good technical writers do well. But it doesn’t suffer from the excesses of this style either, which can sound like getting a lecture from a hipster. In fact, the budding tech writer could use the book as model for writing up his own portfolio.
I gave the book four stars instead of five for three main reasons. First, I think he could have filled out some of the sections with more detailed explanations and examples. For example, he mentions the stages in the writing process–e.g., planning and research, audience analysis, etc.–but he doesn’t explain what exactly these entail. I know what they mean; but a newbie is going to be guessing or looking them up. A little more direction in this and other sections is in order.
Second, one of the virtues of firsthand accounts (i.e., the “how I did it” books) is that you often get good ideas from little experiences the author had. I mean the kind of tales of strange problems and how they were fixed, or little things thrown into a resume or said in an interview that made all the difference. He provides a few good nuggets, but he could have thrown in more. Asking fellow tech writers for some anecdotes might have been a good idea.
Third, he should have provided more about resources like the one’s I mentioned at the outset, and what the average novice needs to get out of them. Gill recommends a few guides, but he should’ve explained some of their virtues and some of the weakness of others. For example, one of the basic skills lacking in your average undergraduate who knows how to write clear sentences is knowledge of how to structure various kinds of documents. You need to know how to write succinct, formulaic explanations (e.g., for FAQs), and how to write things like executive summaries, white papers, abstracts and bibliographies–even letters. These aren’t usually covered in university, yet they’re important skills.
I’ll mention a fourth, though less as a fault and more as a recommendation. Gill mentions “fit” and making sure you and your goals mesh with the firm’s. I agree. But one of the main sources of friction between younger people and their prospective or new-found employer is professionalism. (I include plain old etiquette in here.) Sure, they don’t expect it at university, and they certainly don’t teach it outside business schools. But young people really need to know how to act when they’re in a professional workplace because it will count for a lot more they think.
4. Overall assessment
I think this is a solid how-to book for anyone who wants to know how to become a technical writer. Like Gill says himself, I wish I would’ve had a book like this when I started out. It would have saved me a lot of misery. But I do think it’s too concise; it’s like the stripped down version of the definitive book on becoming a technical writer. Hopefully he’ll address this in a second edition. All the same, I recommend this to anyone who wants to know how to turn himself into a technical writer.