Internetworkers: http://www.ibiblio.org/internetworkers/

[Steven Champeon <schampeo AT hesketh.com>]

on Mon, Oct 13, 2003 at 12:55:41PM -0400, Tanner Lovelace wrote:
> While David sees opportunities for SQL discussions, I see opportunities
> to ask about writing. :-)

Careful, Tanner, this is viewed as sure sign of mental illness by
everyone who has ever written for money. :)
 
> Specifically, I'm curious about how people get into writing technical
> books?  I assume you probably didn't start off writing a book as your
> first project, but even so, how did you get into it?  Did you start
> out writing short articles?  Giving seminars at local tech groups?
> Teaching? etc...  If you have a good idea for a book (or even something
> written already), how do you go about finding a publisher?  (or is it
> better to publish it yourself?)  What else needs to be asked?  Thanks.

I agree with Maria - don't look into book writing unless you're a
glutton for punishment. :)

I started out in a weird sort of way - I interviewed Lou Rosenfeld for
my Web site, and struck up a friendship that led to lots of exchanged
email, which led to an invitation to do a technical review of his and
Peter Morville's book, "Information Architecture for the World Wide
Web". O'Reilly pays many people each a pittance to read their books
under development and give whatever feedback you want; less stringent
than a pure technical edit, they figure more eyes make for less problems
with the final book. They also have technical editors, but they are,
I believe, somewhat rare in the technical review approach.

I tried to pitch that into a companion book, which would have been a more
technical discussion with examples of how you might implement the 
suggested approaches they outlined. But they didn't go for it, mostly
because I was an unknown quantity, had very little published work, and
because the editor was somewhat concerned about whether the first book
would sell (as it turns out, her fears were baseless) and so a companion
was seen as perhaps more risky than usual. Oh, well. I've gone on to
write for their Dev Center and O'Reilly Network, tech edited and tech
reviewed several books for them, and was a contributing author on the
latest edition of "Unix Power Tools", so I must not have done too badly.

I started writing articles for developer.com back in 1997 or so, based
on some mouthing off I'd done on a few mailing lists ;) This led to a
few more gigs, with the usual suspects, most of whom are now defunct,
and eventually led to me writing for Webmonkey, O'Reilly, and Apple's
ADC, among others.

I wrote four chapters for a QUE book that was never published, which
is probably for the best, back in 1997, also based on a contact made
on a mailing list. The editor went into another line of work, IIRC.

I got into tech editing by way of Simon St. Laurent, a friend who I'd
met at an Internetworkers meeting, IIRC - he was writing an XML book,
and I worked with him on that and as he'd done a DHTML book as well,
eventually his editor asked me to pitch a book of my own. At the time, I
was interested in DHTML as a rapid prototyping tool for regular GUIs,
and eventually wrote "Building DHTML GUIs" with his editor, Ann Lush, at
IDG/Hungry Minds. I tried to update that thankfully obsolete book back
in 2001, and instead was offered a chance to write the "DHTML Bible",
but after 9/11 the tech pubs market crashed and crashed /hard/, so there
are now 1000pp of great and current DHTML writing sitting on a disk
somewhere that will likely never be published. We got to keep the
advance, but there were five authors, and nobody was very interested in
handing back the advance to get the book's rights back to take it to
another publisher, and finding an interested publisher who was willing
to publish the whole book proved impossible.

I figure I've worked on almost twenty books now, as a technical editor,
development editor, and both lead and contributing author, and written
maybe two dozen articles over the years. Almost all of these have been a
"someone I know" situation, though subject matter has also driven a lot
of the offers ("Hey, you edited Simon's book on XML, would you care to
edit this book on XML?") as have contacts through the conference circuit
("Hey, I saw your presentation on blah at SxSW - care to write an
article that doesn't contain bullets?").

The best way to get into it is to start with technical editing, where
you can demonstrate the three things that tech pubs editors care about:

 1) you can meet deadlines (e.g. write. a LOT, quickly)
 2) you have some technical expertise in one or more areas
 3) you like working for very little money

Note that they don't usually care if you can write well or not, they
pretty much assume that as editors, their job is at least partly to go
through and correct all of your grammar and spelling mistakes. Weird,
but true. They /do/ care if you can speak clearly about a technology
or software package, and audience is very important, too.

A reliable tech editor can develop a relationship with an acquisitions
editor or development editor fairly quickly.

Having published articles under your belt helps, too, but as Maria says,
writing articles is also a lot more lucrative, involves a lot less time,
and I prefer the format to most long book projects. But nothing beats
the dead tree *thump* a book makes when you throw it down on a desk. ;)

Nevertheless, I decided back in 2002, after the DHTML Bible debacle,
that I'd stick to editing. I'd really enjoyed development editing Jeff
Veen's "Art and Science of Web Design", so I wanted to find more
development editing gigs, but for the most part I've been busy with
other things, so I now just write the occasional article and maybe do a
few chapters for other people's books (such as "Cascading Style Sheets:
Separating Content from Presentation", which was written primarily by
Owen Briggs, and which will hopefully have a second edition out early
next year). I'm trying to decide whether to write another book now,
as I have a couple of offers on the table, and it's really hard to get
over the mental block and memory of fresh pain. ;)

I've been lucky to have made a lot of good friends over the past ten
years or so, many of whom have helped me get involved with speaking at
conferences and so on, all of which has helped to expose me to a group
that tends to be pretty busy and either does a lot of writing, is always
looking for writers, or looking for editors. That's how I got gigs
writing articles for Apple, Webmonkey, Web Techniques/New Architect, and
doing editing for New Riders and a few others. My friends and folks I'd
shared roundtables or panels with at SxSW and the Miller-Freeman/CMP
Web shows were writing and needed an editor, or were publishing and
needed authors to fill out their Web and Internet related series.

I'd recommend that you offer your services as a tech reviewer or
editor to someone you know is writing a book, if you really want to
go the book route - this will give you an idea of how the process
works, whether you want to do the work for the pay (generally pretty low,
especially for first-time authors), and will get you exposed to a
few editors. It may also get you familiar with the various publishing
houses in tech pubs, though that may take a few gigs, obviously, with
different houses. Everyone has their own style of working and process
for handling the job of turning manuscripts into finished product;
the Macmillan folks and their imprints usually use Word (for the comment
and change tracking features) but some, like O'Reilly, often prefer the
old troff or newer DocBook formats (which is fun, if you like editing
SGML/XML by hand :)

If you want to take the article route, become familiar with the various
publications that cover areas with which you are familiar, and approach
them about their submission guidelines and editorial schedule. That way,
you can submit ideas that might help them serve their core audience.

Having some writing samples, even if unrelated to the subject area at
hand, helps, too. One way to get those is to volunteer to write for
sites that accept free content, like INW. If nothing else, it's good
exposure, or can be, and a good way to decide whether you want to do
that kind of work for not much more money. And it is a good source of
feedback, too.

And keep going - don't be discouraged if you get turned down, just keep
submitting. There's a huge need for good, technically astute writers,
and editors tend to develop loyalties to the ones who can meet, or beat,
a deadline and write articles that their audience likes. And if you want
to parlay that into a book writing career, it helps. But you may find
that spending the better part of a year (or two or three, even) writing
something that will probably pay you less than minimum wage, be obsolete
in five years, and carries other hardships just isn't worth the effort.

Let us know how you do - I probably can't help put you in touch with
many Linux-savvy editors, as that's not something about which I do much
writing, but feel free to contact me offlist if you have other skillsets
we haven't mentioned. I write primarily about Web technologies, with an
occasional Apple/Mac slant, and know quite a few folks who are always
looking for content in that vein, and have friends who are editors at
New Riders, O'Reilly, Macmillan, APress and Wiley, among others.

Oh, and one other thing - if you think watching car companies buy each
other up is dizzying, you would simply not believe the way that
publishing houses buy each other up. When I started editing Simon's
book, it was for M&T press, which was bought by Henry Holt, which was
bought by IDG, which renamed itself to Hungry Minds, and who was
purchased by Wiley, all in the past five years or so. Macmillan bought
New Riders, then was itself bought by Pearson. Peer launched an imprint
called Glasshaus, which put out a couple dozen great books before Peer
went belly up rather spectacularly (they put out the CSS book I did with
Owen, and we're largely doing another edition with a different publisher
so we can actually get paid). 

You'll learn rather quickly to keep friends as they move from one
publisher to another, as well - in publishing, like in so many
relatively fixed industries, the best way to advance through the ranks
is to jump from a job at one level at one publisher to another at a
higher level at another, then back. It's a funny business.

HTH,
Steve

PS: this message is about the average length for a tech pubs magazine
article; 1800 words or so. Many just want 1000, some /require/ it, for
print space concerns that don't usually bother the online folks, and
so forth. But if you write for print, be sensitive to their needs in
that regard; their hardest job is often figuring out how to cut your
great 2000 words into 1500 that don't butcher the topic. ;)

-- 
hesketh.com/inc. v: (919) 834-2552 f: (919) 834-2554 w: http://hesketh.com
Book publishing is second only to furniture delivery in slowness. -b. schneier