Dear new developer,
I suggest you take some of your ample free time (if you have it) and write a technical book. I’ve written one book and doing so gives you a deep understanding both of the technology you choose to write about and of the difficulties of doing so. It will give you instant credibility should you choose to pursue a job related to the technology. You can use it to make connections and give speeches at meetups.It may even make you some money, but don’t count on that.
Pick a technology that you use at work or on a side project. Characteristics you are looking for:
- few books have been written about the topic
- you are really really interested in the topic and want to master it
- it is something you use regularly
- the technology is either really new (and you think you might be able to do multiple revisions) like React, or is really old and slow moving (like bash)
- it’s something relatively popular or new
I made a number of mistakes when I wrote a book about command line hooks in cordova (which is a framework for writing mobile applications). The mistakes I made included:
- the market for cordova books was small, and the subset of people interested in automation of cordova actions was even smaller (even so, I found about 70 people willing to pay for the book)
- I picked the technology because we were using it at the time, but after one project we stopped. I wasn’t really interested in mobile development, and so never updated the book.
Topics that aren’t technical are more evergreen (how to manage a software team has changed in the last 20 years, but how to build a javascript application how changed in the last 12 months), but there are more books out there about them as a result. Technical books have a shorter shelf life but also have less competition.
However, if you can find a topic you want to write about, don’t start writing the book from scratch. Instead, outline it and write a number of pieces of the book. An easy way to do this is to create a category on your blog (you have a blog, right?) and start writing regularly about the topic. Write an outline and add blog posts based on the outline.
After four or five blog posts, you’ll know if this is a technology you want to dig into and publish a book about. Keep writing the posts, but start looking for communities where the technology is published. Start answering questions about it on the forum and/or your blog. Set up an email list to capture people who are interested in your topic and visit your blog.
The risk is low. If, on the other hand, you write two articles about technology X and you are bored out of your mind, then just stop and don’t create the ebook.
Once you have about 20 posts, you can start thinking about pulling them together to form an ebook (the exact number depends on the size of your topic). I used leanpub and had a great experience. Note that you’ll be entirely responsible for not only writing the book, but marketing it. However, you get to keep something like 90% of the price of the book. Leanpub can pull an RSS feed into the leanpub format and you can use it to suck down the posts you’ve been writing.
After you do that, it’s really about continuing to fill out the outline, updating your forum posts to include a link to your book site, and marketing the book. I’m no expert there, but made about $700 bucks from my ebook. I don’t think I ever calculated the exact hourly rate, but I can say with confidence that it was far lower than I could have made contracting.
So, in the end, why is it valuable? I think writing a book, even a 40 page ebook like I did, challenges you to think deeply (to understand the technology and convey it in a way that other people can understand) and broadly (similar to holding a really large software system in your mind). These are both really good skills to acquire.
Sincerely,
Dan
