Saturday, February 12, 2022

Some quick thoughts about writing a first book

A few times in the last couple of months, I've been asked about the writing process from people who are thinking about or planning to write their first technical book.

Here are some of the things that I'm telling those people. I'm putting it here because others might be interested and because it will make it easy for me to find (and refine?) in future, if necessary.

  • It's LOTS of hard work. It is very unlikely to earn you much (any?) money. (Especially if you're used to being well paid for your time as a developer.) Are you sure you REALLY want to do it? 
  • Be prepared to spend (you should be spending) more time planning and re-writing that writing.
  • Interview the publisher. Assess if you want to work with them like you would (should) any employer. Do you get on with these people? Do you want to spend lots of time talking with them? Can you trust them?
  • Speak to authors who have worked with the publisher before. Find ones with good and bad experiences. Find out who at the publisher the author worked with. It's the people that matter more than the publisher as a whole.
  • Understand why the publisher wants a book on the subject, and why they think you'd be good to write it.
  • Technical reviewers are at least as important as the editor. Get lots of feedback from the technical reviewer on your detailed outline for the book. They'll help avoid any big issues not being identified until it's too late (there's not enough time) to fix them.
  • Write ALL the code before estimating the wordcount for a chapter. If your book is mostly going to be explaining code or APIs. Yes, this means you have to have a really detailed plan and have done a lot of the work to be able to write the outline and before you sign a contract and start "writing" the book. For reference, I think four lines of text to every one line of code is a good guideline as it's explaining, not just showing the code that's important. You'll also discover that code is actually a lot more lines of code than you imagine in advance.
  • Have a backup plan for what to do with your planning work even if you don't finish the book. (A series of blog posts is an obvious answer.)
  • Avoid working with a publisher that has very strict structure and expectations for a "type" of book if that's not what you want to write. You probably won't get as much support as you'll want/need and it's harder for them to help you.
  • Triple check everything. If it's your name on the cover people will attribute any mistakes or issues to you. (Don't always rely on other people using the change tracking functionality of software or documents correctly.--Guess how I learned this.)
  • Ask the publisher for the guidance they give to new authors after they sign the contract, but before you sign a contract. These guidelines often include lots of useful information that will help you write the outline--that will lead to the contract. Consider it a red flag if they won't share it. Speaking of which...
  • Trust your gut. I've not (yet) met any authors who had doubts about a publisher at the start but they turned out to be unfounded. I have met many who wish they'd paid more attention to the things the red flags they saw early in the process.


I hope this helps.

0 comments:

Post a Comment

I get a lot of comment spam :( - moderation may take a while.