The ongoing recession in the high-tech sector urges software developers to seek alternative sources of incomewriting technical books, for example. Unfortunately, many of those who turn to the tech book industry base their decisions on unrealistic expectations of fast cash. It's advisable to become acquainted with the IT book business and learn how it works before you decide to take the plunge. My recent experiences as a technical editor (TE) of Nick Chase's XML Primer Plus (Sams, 2002, ISBN 0-672-32422-9) and as the author of ANSI/ISO C++ Professional Programmer's Handbook (Que, 1999, ISBN 0-7897-2022-1) may help you to decide whether the tech book business is suitable for you.
Why Edit If You Can Write?
For someone like me, who has written one book and co-authored another, the decision to become a technical editor might raise eyebrows. If book writing can be compared to a software development project, with the author serving as a team leader, the technical editor is equivalent to a quality assurance (QA) engineer. Could you enjoy this job? The answer is "yes," as long as you become a technical editor for the right reasons.
As interesting as XML is, my decision to become a technical editor for XML Primer Plus was mostly based on personal grounds:
Writing my first book in 1999 was a rewarding project. I thought that technical editing would enliven those good memories without submerging me in a full-blown authoring project.
I hoped that technical editing an XML book would spruce up my XML expertise and let me learn a few tricks from a real expert (the author).
Producing a book is a project that engages a team: one or more authors, an acquisition editor, a development editor, one or more copyeditors, and at least one technical editor (as well as a whole team of layout and production experts later on). The atmosphere of a small and highly professional team working togetherwhere every member would contribute his or her unique expertise (and a good sense of humor)certainly had its lure.