Why YOU should write that eBook

Tag: Anything

I think that opening quote by Claudio Zizza is a brilliant one. "You! You know something other developers would be amazed of. But you don't know what it is because everything you know seems regular to you". That means *all* of us. Even you.

I'm going to use a lot of quotes in this post (or at least reasonable paraphrases, and try to get them correctly attributed). This one I took from Robert "Uncle Bob" Martin - "The number of programmer in the world doubles every five years. That means, *at any given moment*, half the world's programmers have less than five year's experience."

Clearly, the world needs instructors.

It needs people who have "done it before". Anything. It needs people who can explain their experience so that others can get up to speed more quickly. That's all. That's you.

I'm a programmer, and my quotes are from the programming world, but your experience doesn't have to be. Grow bumper crops of tomatoes the last five years? Tell us how you did it. Found the best hiking trails in Japan? Share!

The biggest object people have to teaching is they feel they are not experts in the subject. The truth is - they are, or easily can be. So let's take that idea and lead you to writing your first eBook.

How do I pick a subject?

I inwardly cringe every time I read someone say they are going to write "A Beginner's Book on X". There are two problems with this (and no, "we already have 1,000 of those" is not one of them). First of all, to me this is the classic case of "I want to write a book, but I've only got enough expertise to do beginner level stuff." I have a tip for you. Beginner level material isn't any easier to write. But the real issue is that the subject is too broad. What's the difference between beginner and intermediate? Where do you draw the line? How many seemingly related tangent subjects do you cover?

A book that is too broad will probably never be finished.

My first eBook - which I called an "ePamphlet" and was really more of a reference with comments - was Laravel Collections Unraveled. I came to write it because there are two functions in Laravel called `where()`, with different syntaxes and different uses, and I was constantly getting them confused while I was working. So I dug into the source code to see what the difference was. Lo and behold, there were two classes called Collection, each with their own version!

It turned out, there were a lot of other functions on those classes, so I started tweeting some of the interesting things I was finding. Those were popular, so I wrote a blog post with six of my discoveries. That became one of my most-read posts, so I expanded to my "book".

In other words, I wrote a book about a single class library. Something narrow that I knew deeply.

I'm not an expert on anything.

Oh, but you will be! Want to know something? The people who go out and write "real" books - they research them. There is no reason to think you already have to know everything about your topic. You don't have to hide the fact you are writing a book when you ask someone to explain some finer point to you.

People can find your information elsewhere. They read your book because of how you tie that information together and present it.

Have you ever read a work of non-fiction? Sure. Have you ever read a work of non-fiction that was about something no one in the world had ever written about? Probably not. You most likely knew the outline of the facts before you picked it up. You read it for the presentation, the new insight, the author's perspective.

Have some subject where the documentation wasn't up to snuff? Collect your notes, flesh out the gaps in your knowledge, and present your findings. Each time you start to write about something you aren't 100% certain of, find out. You will become that expert in a very short time. You may be surprised, but that will be one of the most rewarding parts of the whole project.

No one will read it.

No one will read it, or no one will buy it?

Ah! Let's be clear - most books are not good returns on investment. You'll make more per hour cutting your neighbor's lawn. 1,000 sales is pretty good, and that's if you are doing things in a very professional manner. If you are after recurring revenue, that's fine, but that's hard work. I'm encouraging people to write, not write for profit. My first effort I gave out for free.

Aside from the personal satisfaction of having written a book, there are a great many benefits:

  • You learn something that was already important to you inside out (Ask me about getDictionary(). Go on!)
  • You can give something back to the community (without writing you own framework)
  • You gain prestige in your field or hobby. ("That's the guy that wrote the book!")
  • You may have opportunities to present at conferences (so you don't have to bore your friends about it any more)
  • You may find writing to be a lot of fun, and start doing more blogging, books, etc.
  • You will build up an audience for the next book

Why not a blog? I think you can go more in depth with an eBook, and thanks to technology, you can continually add to it and notify your readers. People expect books to be longer and will read it in parts; blogs, not so much.

Should I charge? Yes. I know, I didn't. I didn't feel my first effort had enough original content to warrant it. My other projects will not be free. Time is money - you would pay an admin assistant to manage your correspondence, right? You are collecting, collating, organizing and editing important information for your readers at a fraction of what it would cost them to do it themselves. Expect compensation.

How long should it be? As long as you need to cover the subject the way you want to. The nice thing about digital print is you don't need to reach that magical 240 pages that a printed book needs to maximize sales and pay for all the distribution and support. Write what you need, and mark it clearly.

English isn't my first language. Write in your language. Or write in English, and find a someone to edit. But, if you are charging, expect to pay your editor, okay?

Hopefully that was inspirational - now get out there and write!

Read it Monday, Use it by Friday!

Laravel Quick Tips Weekly Newsletter. Short, immediately helpful bits you'll use in your own codebase before the next one arrives.

Join us now and get a FREE PDF of the first fix months of Laravel Quick Tips!

No Spam, Unsubscribe Anytime

Contact me