DEV Community

Cover image for 5 lessons learned from writing a tech book
luminousmen
luminousmen

Posted on • Edited on

5 lessons learned from writing a tech book

So I wrote a book.

I've never had anyone I know write a book. I decided to do it myself as an experiment, and I want to tell you a little bit about it. Maybe one day you can learn from my example.

Writing a book is fucking hard, it is hard work, especially when you are not Stephen King. It is even harder when the publisher has a hard deadline. Fortunately, I did not have such conditions — I published the book myself and did the whole process from beginning to end. But I spent some time digging through Reddit threads dedicated to authorship for publishers like Packt and O'Reilly. And made some conclusions which I want to share.

1. Motivation

Let's start with the most interesting thing — it's unlikely that you'll be able to make money on a book. But if you work with a publisher, the book is paid in advance and you get a commission.

But no matter how you publish, with or without a publisher — you will spend a lot of time on it, far too much. If you convert the time spent on creating a concept, R&D, code writing and testing, design, formatting, publishing, and writing the material itself into hourly wages, you will realize that you "worked" at a loss.

And this is well understood not only by me but by many authors when they agree on writing a book. The motivation is as follows:

  • New experience
  • Prestige and opportunity to add the word "author" to your LinkedIn profile, i.e. personal brand.
  • 4 upper levels of Maslow's hierarchy of needs
  • "If you are doing something good, do not do it for free"

My motivation was the same.

Technical literature has a very small audience, and there is no need to have illusions about the number of sales. After all, I am a modest engineer who does not write bestsellers. Judging by my Reddit research, many authors spend more money on R&D than they end up earning. At least, on their first book.

2. Skills

The next point that is important to realize when you think about writing a book is that you need skills.

The skills not of what you're going to write about (although it goes without saying), but the skills of writing and presenting the material.

I do not have such skills — so writing was very hard for me, despite the fact that most of the material was already somehow more or less ready — taken from my own posts. It's hard to read the same thing for the fiftieth time and try to make clear and consistent sentences so it can be more or less easy to read. I don't even mention English.

In any case, it's better to refine a book than to release a raw one. It sounds obvious, but I have had to refine a book that has already been published. This approach ruins your credibility in the eyes of your readers. Aleksandr Solzhenitsyn describes the rule of the last steps — when 95% of the work is done, there is nothing left, but that 5% of the work is the most difficult in terms of motivation and the most important in terms of reader comfort.

3. Book topic

It is a book about asynchronous programming. The topic I chose at random — I can't say that I write asynchronous code every day and know everything about this topic, but I think I have a good understanding of the concepts and had experience writing such applications. And it seemed to me that few people understand and write about this topic at the concept level. In fact, I decided to help people like me — to solve questions that sometimes arise in my head. Also, most of the material was already written in my blog which made the whole process a bit easier.

Technical literature, in general, is difficult to write properly. It is necessary to understand roughly the knowledge of the potential reader. You need to choose the right terms and use them consistently. And you shouldn't go far from the topic (which I did not really succeed). And you have to write not just clearly but structurally correct — approach the topic/concept from the right side, move smoothly from one chapter to another, and draw conclusions, even the obvious ones.

The logic here is very simple. The material should be the one you want to read and advise your friends, that you as an engineer buy in the "working" library. This requires not only a thorough knowledge of the topic but also the right approach to deliver it in such a way that the reader understands the material and does not die of boredom.

4. Formatting the book

The author's work does not end after all chapters have been written. It is in the author's interest to help in R&D, correct formatting, participate in book marketing, and fill in product pages and descriptions.

Self-publication is much more complicated than a traditional publication. No one provides you with an editor and design team, so you are responsible for the whole project. If you happen to have friends or colleagues who can help you with any part of the work, it will certainly make things a little easier. But self-publishing still requires a lot of work and sometimes investment(in design, formatting, pictures, etc).

For me, formatting the book was a nightmare — I couldn't find decent tools at all. And I wasn't just looking for free ones. I went through a cycle from latex, pandoc, designer, calibre, google docs, Kindle Create, iBooks Author, and several others.

As a result, I wrote and format everything in google docs and then moved it to Kindle Create for Amazon publication.

The biggest problem with all those tools is code formatting — in google docs I managed to write it with widgets. But in all other places, you don't even have options — using pictures or writing a heap of CSS.

I stick with images and it looks disgraceful, but at least it does the job on all formats and sizes. In Kindle Create even text cannot be selected!

After I've finished the book I found out the better way to format and write ebooks. And I would recommend using leanpub.com for that. Not only they provide you with great tools for creating ebooks, connecting authors with readers, managing sales, landing pages, and the like, they are also heavily involved in advancing the industry with new standards such as Markua (a book-targeted, enhanced flavor of MarkDown). And it even can generate all required formats(pdf, epub, mobi) and it's free!

5. Publication

In the end, I published the book in kindle, pdf, and epub formats on several websites — amazon, leanpub, gumroad.

  • Amazon is the easiest resource for publication but it only for kindle format and the royalties are very low — the author gets only 30%.
  • Gumroad is somewhat dead — I've got just 6 views total on this platform, no sales. Maybe it's only me and my not that popular theme and book but anyway.
  • In my opinion, leanpub is by far the most usable, well-crafted service on the market for ebook authors, and I couldn’t recommend them more. I like learnpub for its very straightforward approach. Easy to set up everything and it's pretty nice to look at the end result. And the royalties there is 80%! No, it's not an advertisement.

Conclusion

So the conclusion — I can't say that I'm very proud of my book, but I'm certainly not ashamed of it. It was an interesting experience for me. Probably one day I'll try to write it again, and maybe something closer to my topic of interest. Maybe Spark book? Hey, publishers let's talk! 😂

Useful Links


Thank you for reading!

Any questions? Leave your comment below to start fantastic discussions!

Check out my blog or come to say hi 👋 on Twitter or subscribe to my telegram channel.Plan your best!

Top comments (0)