Techies-turned-authors put their expertise in print.
In the IT realm, there are newbies, novices, experts and gurus – and then there are published authors. It takes a certain level of expertise, self-confidence, self-promotion and, above all, good grammar and writing skills, to make the jump from IT professional to IT author.
The path from IT or network professional to IT/network book author can be as circuitous as a packet’s path across the Internet. IT pros who have written books in the areas of their expertise come from varying backgrounds – from English majors turned techies, to engineers with excellent grammar and punctuation skills.
Those whose names have made it to Amazon.com and the computing/technology shelves of Barnes & Noble offer a few suggestions: know what you’re talking about; research it again; and plan some long, hard hours of word-processing.
Compensation for books varies widely by publisher, according to IT authors who have been through the publishing process. Some publishing houses give advances to authors, while others provide royalties based on the amount of books sold.
Michael W. Lucas, author of Cisco Routers for the Desperate, says that from taking money upfront may be tempting, but holding out for royalties is worth it. “You make far more if you’re willing to wait for your money and take only royalties,” he says. “But if you need the cash right now, you can take that option. If you take an advance, it’s important to remember that that’s probably all the money you’ll see from the book. Very few books earn out their initial advances.”
While it may seem obvious, one prerequisite for aspiring IT authors is to know what they are talking about. “There’s a large gap between knowing something well enough to do your job and knowing it well enough to be able to write a book about it – and to not to receive pointed e-mails from readers of the book calling you an idiot,” Lucas says.
Unlike blogs or some Web-based how-to sites, technical books will be your final word on a topic in a format that cannot be changed.
“When you’re writing a book, it’s out there forever,” says James Trulove, author of LAN Wiring (third edition), Build Your Own Wireless LAN and Broadband Networking. You really have to be right.”
This means that as much as a writer may think he knows about a subject, there is always more to learn.
For Trulove, this involved lots of primary research; 802.3 documents from the IEEE became regular reading when he was penning a tome on Ethernet and network cabling.
“Don’t kid yourself; this is a lot of work,” he says. Ultimately, the research made his books stronger and taught him some new things on topics he thought he knew completely.
Just as important as writing accurately is writing clear, understandable prose, authors say. Misunderstanding or misinterpreting correct information is just as bad as reading incorrect information, they say.
“Knowing the audience you’re writing for is important,” Trulove says. “You have to write so that any reader can understand it, not just someone with your same skills and knowledge.”
Others think of it in programming terms.
“You have to edit your words just like you would do [quality assurance] on your code,” says Priscilla Oppenheimer, author of Troubleshooting Campus Networks. “Once you’ve written something, leave it aside for day and try to read it again to get rid of all extra verbiage.”
Good techniques for making sure your technical prose is understandable include reading the text out loud or having it read by someone who speaks English as a second language. The latter technique is especially important, with the swelling ranks of IT professionals with international backgrounds.
Choosing the right topic is key in getting the attention of technical-book publishers, IT authors say. Finding a niche, or working with a technology in the early stages of its development are some paths to publishing success.
“Working on something that’s new or timely is important,” Trulove says. Before writing his first book, Trulove was busy extending RS-232 terminals with twisted-pair network cabling – a relatively new medium in the industry. Later he was involved with companies that were among the first to transition from LAN coaxial cable to twisted pair.
“I was in on those technologies very early, which gave me some good material on a technology that was new and hot.”
Finding a new angle on a topic is another method to consider. Oppenheimer says few network how-to books then provided a systematic approach to network design. Working as a programmer for Cisco at the time, she says that bringing a methodology to the book helped fill a gap in the market.
“We learned the hard way that you can’t just throw things together, which is how a lot of networks used to be built at the time,” she says.
Lucas also took a different slant on a widely covered technical topic when writing his Cisco book.
“There are many big thick books on Cisco,” Lucas says. “Cisco technology is powerful, and you can do huge amounts of things with it, but 90% of Cisco users only use 5% of the technology. So I decided to write a book about that 5%.”
The initial draft for the book came as a result of documentation he had written for a tricky router configuration at his former job at an Internet service provider. “I had to write it all up anyway, so I figured I may as well polish it up a little more and make a book out of it,” Lucas says.
For the BSD operating system, Lucas found many anecdotal tips and mailing list threads, but no big books on the topic.
“I essentially spent a year reading mailing archives and translating the hurried notes of very smart people into English.” The results were Absolute BSD and Absolute OpenBSD.
Hot or topical technologies may get the attention of publishers, but writing on the subject is a careful balance of specifics and generalities, as books on hot IT topics can have short shelf lives.
Lucas says that in his first book, he outlined specific instructions on how to install a piece of software from a certain vendor. Two weeks before the publishing date, the vendor changed the installation process, requiring a last-minute edit.
Other technical areas have greater shelf life. “Lots of Unix commands have been around for 30 years,” he says. “In Cisco command-line interface, they may add new things, but commands that worked 10 years ago generally stay in the code base.”
