ne of the great advantages of being a developer is that your skills are in demand in virtually every industry. That means that when the job market dries up, developers are in a better position than the average worker to find other ways of turning their knowledge into income. And the book publishing industry is likely to be one of the first places to which ambitious developers turn.

High-tech books are not selling as well as they were a year or two ago, but that doesn’t mean that publishers aren’t making new books. On the contrary: there are opportunities at many book companies for authors, technical writers, and technical editors. Many developers are attracted to these opportunities, not only for the potential of additional income but for the opportunity to learn something new and get professional recognition.

Unfortunately, many of those who turn to the tech book industry base their decision on unrealistic expectations of fast cash. It’s possible to make a lot of money by authoring a book, but it is far from the norm. A book that sells an average number of copies will not repay you with riches. Therefore, it’s advisable to become acquainted with the IT book business and learn how it works before you decide to take a plunge. You should also consider carefully what your motivations are; in actuality, money should probably be the last reason why you undertake an authoring or editing contract.

I’ve been both an author and a technical editor. Most recently, I was the technical editor (TE) of XML Primer Plus by Nick Chase (Sams), and my book, ANSI/ISO C++ Professional Programmer’s Handbook was published in 1999 (Que). My personal experiences will give you an inside look at the rewards and challenges of entering the high-tech book business, and may help you decide whether it’s suitable for you.

If book writing can be compared to a software development project, where the author is the team leader, a technical editor is the equivalent of a QA engineer. The duty is to check the technical accuracy of the entire book, including, among other things, correct and consistent terminology, verifying the accuracy of all figure references, and testing all the author’s code. Code testing isn’t just a matter of copying text to an IDE and running it. In many cases, I needed to embed it in a driver program to make it compile. So why would someone who has already written a book and co-authored another, decide to become a TE?. Could one enjoy this job? The answer is yes, so long as you do it for the right reasons.

In my case, my primary motive was nostalgia. I had had such an excellent time working on my first book, and gotten such rewards from it, that I was eager to participate in another book, but this time without the all-consuming commitment of being an author. The atmosphere of a small and highly professional team in which every member contributes his or her unique expertise and a good sense of humor certainly had its lure.

Second, I had hoped that this job would spruce up my XML expertise and teach me a few tricks from the author, a real XML expert. As a fledging language, XML is constantly evolving. Writing a book on a language that is changing rapidly seemed an adventure, and I was not disappointed on that score. I also knew that we wouldn’t rely on XML exclusively since most XML-based applications use a “hosting language” such as C++ or Java under the hood. The combination of XML and other languages seemed enticing although it did present a challenge for us.

Nick, the author, decided to use Java as a hosting language throughout the book. However, in order to demonstrate the language-neutral nature of XML, we decided to include examples in C++, VB, and Perl in some chapters. To accomplish this, we hired programmers to write the additional code and test it. What we didn’t plan for was the additional page space this code would consume. In quadrupling the code listings, we exceeded our page count and wasted precious time. We had to scrap the additional code samples in all but a few chapters, where it was most useful, and stick to Java in all the rest. This is just one example of the many frustrating things that can happen on a book project, and if you decide to work on one, you should expect things to go wrong from time to time.

The Perfect Job for You?
Technical editing is not a job for everyone. Obviously, you need strong technical and written communication skills, but you also must have self-discipline, a sense of duty, and a hawk’s eye. You must keep pace with the team, because the author(s), development editor, and copy editor need to review the manuscripts with your comments. Failing to return manuscripts on time will create a bottleneck.

To tech edit a chapter usually takes 1 to 2 whole days. It is a laborious and exigent task. A typical chapter contains 40 pages (in Microsoft Word), 15 to 30 code listings, and dozens of figures. Concentration and patience are the name of the game. If you have a daytime job, technical editing might not be suitable for you. The last thing you want after a quarrel with your boss and a traffic jam on the way home is 10 more hours of code testing. But if you have a reasonable amount of free time and the discipline to keep at it every day, it can be managed.

You should be prepared to deal with fluctuating rates of work. Some weeks you’ll be swamped with four chapters that must be ready within days; on other weeks you won’t have much work to do. Often, you’ll have to review the manuscripts twice because the author has inserted new passages or rephrased some paragraphs based on your comments.

But I’ve avoided the million-dollar question. How much money can you make doing this kind of work? The usual fee is $2.50 to $3.00 per electronic page. Your plans for an early retirement may have to be shelved: For a typical book of 20 chapters, you can expect to get about $2,000. As an author, you can expect to get an advance of about $5,000 (this sum is usually divided into 3 to 4 payments for each part you complete) and 8 to 12 percent of royalties, depending on your experience and negotiation skill.

If you are eager to write your first tech book, taking a position as a technical editor will give you exposure to the process as well let you initiate contacts with influential people in the industry. It’s very helpful to be visible, so acquisitions editors (the people who find new authors and make the decision of whether to commission a particular book topic) who are shopping for tech editors can find you. Be involved in supporting users and other developers, thorough mailing lists and newsgroups. Being active in technical groups is important, particularly if your expertise is in open source.

If you don’t already have contacts in the industry, it’s essential to be proactive. Seek out the acquisitions editors of the books you particularly use and like, and express your interest in technical editing. The acquisitions editors are always on the lookout for good TEs, not the least because TEs often end up moving on to writing projects.

Skill and expertise not withstanding, you must love the job. Forget the illusions of fame and fortune; your reward will be the excitement of participating in a new creation. If you can’t get excited about that, you’re better off finding other ways to leverage your programming skills.