What It Means to Be a Writer, Part 1 => Defining Your Book

May 23, 2012
This entry is part 1 of 6 in the series What It Means To Be A Writer

A little while back, I had a series of emails with a reader named Scott, who was considering an opportunity to write his first book. Scott did want to try writing a book, but didn’t want to jump into the project blindly, and so asked me what it meant, in day-to-day terms, to write a book. We had a few long emails back and forth, that I thought I’d edit/expand upon (my parts) and share here for others to benefit. In my responses, I did try to stress the negative aspects of being a writer, so as to present some of the worst case scenarios. What originally started as a couple of long emails became a long post, and now a series of posts. If you’d rather not read it all, the short advice is this:

If you want to write a book because it’s something you always wanted to do, give it a go, but if you want to write a book to get rich, become famous, or the like, you’re barking up the wrong tree!

Note that my perspective and advice specifically focuses on writing technical books and articles, which is what I do and know best, although much of the advice applies to other types of writing, too.

So you’ve decided that you want to try to write a book! The first thing you’ll need to do is define the book you’re going to write. This is a combination of both the specific subject matter and your take on that subject matter. For example, are we talking about:

  • JavaScript for beginners
  • JavaScript for experts (i.e., become a ninja)
  • JavaScript for mobile development
  • JavaScript frameworks (and which framework)
  • JavaScript performance
  • JavaScript on the server
  • JavaScript for internationalization on global Web sites

Those are just seven examples off the top of my head for various subjects under the very broad category of JavaScript. Each of these subjects can get far more detailed and varied. But understand that a book is not just its subject, but a book is also the writer’s take on that subject. For example, my take on a beginner’s JavaScript book would be different than yours. The first goal, then, is to answer the question:

What is it that you want to write about and what do you want to say about that subject?

When I went to write my JavaScript book, I didn’t just want to write any JavaScript book but wanted to write a JavaScript book that explains JavaScript as a language in its own right, that conveys today’s usage of JavaScript, and so forth. Your take on the subject is one of the things that will differentiate your book from similar books on the subject. And there will be similar books, no matter how specific or unique you think you’re being! Your take will also impact whether your book is any good, let alone whether or not it sells.

Knowing the answer to the question of “What do you want to write about and what do you want to say?”, the next question is: are you qualified to write that book? For technical books, “qualified” means both the technical expertise and the ability to write fairly well. If you’re working with a publisher, you’ll have editors that help with the language and tech reviewers that help with the accuracy, but you still need to be strong in both areas. Let’s look at these two skills in more detail.

As for expertise, yes, a technical author must have some expertise, for three reasons. First, what goes in the book needs to be correct. Obviously. Second, you need to come up with examples that are practical and useful. Third, being a writer is mostly about making decisions. This includes not just the examples themselves but what should be covered and what shouldn’t, and in what order. You need the expertise to make the right decisions. In all of these, a tech editor will help but expertise means you also know when to listen to the tech editor and when not to.

Conversely, just having expertise doesn’t mean you’ll write a great book. There are many minds that are greater than mine with, say, PHP, who probably couldn’t write a good book to save their lives. And, one of the benefits of not being a seasoned expert is that you’re closer to when you learned the subject, which can help in writing a book specifically for beginners. As you learn, and you learn what’s confusing, you can easily put that knowledge in the book. On the other hand, make no mistake: the more you know on a subject, the easier it’ll be to write and you’re more likely to make good decisions.

Here’s a personal story: I started writing my first book, on PHP, within about 6-9 months of when I ever wrote my first line of PHP code. In fact, within 6-9 months of every hearing about PHP. I had spent comparatively little chronological time in PHP and that book turned out pretty well, despite everything I didn’t know about writing a book. There were parts of the book that worked, and things I shouldn’t have done in the book but I didn’t have the experience and confidence to make the right decision on. Despite not being a true PHP expert at the time, I still put out a pretty good book, on the whole. My main point about expertise is that there’s a time when you know nothing about X and there’s a time when you write a book about X. Whether the difference between those two points is 20 years or 20 weeks isn’t the critical factor, it’s how you use that time and what you’re capable of. I could write C for 20 years and pick up terrible habits that I would then convey in a book. Having an expertise in a subject doesn’t guarantee you’ll write a good book, but makes it easier for you to write a good book.

The second skill you’ll need is the ability to write good. Er, well. Like any skill—programming, plumbing, dentistry, you get better at writing with practice. Hopefully. When you go to write a chapter, your expertise will be called upon to determine what that chapter should cover, in what order, and what examples you’ll use. Your expertise will help you create the actual code you’ll use in the chapter. But then you’ll need to turn all that information into an actual chapter: explain the goals, explain the concepts, explain the specifics, and put it all together in real-world examples. Teach the reader what they need to know in a nice, neat line that the reader can follow and understand. To do that, you’ll use words. Lots of words. A single chapter in one of my books is 5,000-10,000 words. An entire book is, say, 100,000. No matter how fast you think and how fast you type, that’s a lot of time sitting in front of a computer (trust me: I’ve gained 5 pounds for each book I’ve written). Whatever other illusions you may have about what it means to be a writer, learn this one first: books are only ever written by sitting in a chair writing. That should seem obvious and redundant, but it’s not. There’s no magic to writing, it’s just a matter of continuing to move the cursor to the right, as I once heard Andy Ihnatko accurately describe it.

I will write specifically about the mechanices of writing a book in the third post in this series (I believe), but you need to ask yourself whether you can sit at your desk, or your table, or even a hammock, and churn out hundreds of words, day after day, for weeks and weeks. You may need to write every day, or every day and every night, but most importantly, you’ll need to write when you don’t want to, because you have to. The one saving grace is that while the final writing should be good, [intlink id=”2472″ type=”post”]the initial writing does not have to be[/intlink], which helps to take a lot of the pressure off. Yes, spelling and punctuation and word choice and the ability to string sentences into paragraphs are all necessary skills, but the main skill in writing is discipline. The more you do it, the better you’ll become at it. And just doing it—just sitting in front of that keyboard—is how books get written.

If you think you have the discipline but don’t have the associated skills, don’t automatically cast aside your dream of being a writer. You don’t have to be a great, natural writer in order to write a book, it just makes the marathon ahead of you that much easier to run.

So once you know what you want to say on what subject matter, and you’ve objectively determined that you have the expertise and writing skills to make that happen, the next step is to take the idea of that book and turn it into a book deal. I’ll write about that in the next post in this series.

In the meantime, if you have any questions or comments, please do share.