How I wrote a book about Terraform in 3 months

Illustration of a historical figure in period clothing, holding a quill and a sheet of paper, with a thoughtful expression and finger on their lips, seated in an ornate chair. Illustration of a historical figure in period clothing, holding a quill and a sheet of paper, with a thoughtful expression and finger on their lips, seated in an ornate chair.

February 1st, 2017 I had published my second book: Getting Started With Terraform. The book I wasn't planning to write and which influenced the development of the mkdev project horribly. Writing a technical book on 200+ pages is, as the co-founder of mkdev Leonid Suschev would say, nothing to be sneezed at. That's why I am telling everything as it is. Why? What if you are interested. What if you want to write a book yourself. What if this is a clever way to make you buy this book (no).

The first book — Self education for web developers. Everyone who says that a PDF-file on 70 pages is not a book can try to place this amount of wisdom and advice a beginner would need in such a brief and convenient form. Can't cough up even a couple of pages? Now you understand! And we give away this for free.

How to get a contract for writing a book

Although I have been working with Terraform a lot and for a really long time, I never had in mind to write about it a whole book. To some extent, I am an active contributor of this project - on my account there are 9 accepted Pull Requests. I also like to write bug reports very much - I have whole 11 of them on Terraform. Also, I have written a sheet of text about tools like Terraform,where the comparison did not favor the latter (the comparison was in 2015, since then Chef Provisioning has died).

I can't rule out that all of these factors (and also mentioning Terraform in my CV) have played a part in the fact that in august 2016 a publishing house Packt had connected me with a proposal to write a book about this tool for them. Of course, I had rejected, like I reject most of the projects and offers I receive.

Packt hadn't accepted my rejection, though, and continued to persuade me that it was a great idea to start writing a book until the end of the year. I don't know what I would do if I hadn't been away on vacation but in a familiar flow of work at that moment. But, as a result, for a brain rested by sea, under the sun and with the help of fiction, this idea eventually started to seem profitable, and I agreed.

In a couple of weeks and after some formalities, I had gotten a contract for the book and was able to start writing in the middle of September.

How to write a book in a short time and in English

206 pages in 114 days is no joke. This is approximately 2 pages of text in English in a day. I won't lie that since the beginning I responsibly started to write this amount of pages every day. During the first month the process of writing resembled my college days: don't do anything for a several days (or even a whole week), and then with the burning ass and the magical tea produce 10 or more pages in a row, trying to meet the deadline.

Packt are masters and know how to organize the writing process. I had to send the whole contents list even before the first chapter was written. Every chapter had its own deadline. This way, the process was split into convenient periods of time with 2-3 weeks, at the end of each one a draft of the new chapter needed to be sent to the editor. Then the chapter was reviewed, edited and sent back to the author again for him to approve all the changes and take into account all the wishes and suggestions of the editor.

In total, every chapter was perfected by the editor and the author 3-4 times, up until the final edition which was going to take place in the book. In addition to the base editor, there was also the technical editor, who checked the workability of all the pieces of code (which I hardly believe in), and also made suggestions on changing the wording of some phrases.

Somewhere in the middle of the writing process I took on a rhythm and started to dedicate the book 1.5-2 hours in the morning consistently every week day. Sometimes it was long sessions of struggling words from me. Sometimes instead of struggling words I was spending a long time studying the subject, trying different programs out and making the examples of code.

Even taking into account my huge experience of work with Terraform, I couldn't just sit and write chapter by chapter. I had to think about its different use cases, about overriding its restrictions in one case or another. I had to go beyond my knowledge regularly, look for new approaches, new tools making the work with Terraform easier (in addition to Terraform, the book describes a couple of dozens of different tools), etc...

Frequent new releases of Terraform were adding intrigue to the process. The book had started with 0.6.17 version and ended on 0.8.2, that's why I had to spend half of December rewriting first four chapters.

Most of all, I tried to avoid restating the documentation. Terraform is a tool you can very easily start to use, but it's not very easy to figure out how to use it effectively in a production environment. How to organize the code? How to link it to other tools, like Chef/Puppet/Ansible? How to update the infrastructure? How to organize teamwork, testing, continuous integration? How to pass data for configuration to Terraform the right way and scaled? All these questions the documentation has no answer to. But my book has.

Was it worth it to write a book on a technical subject?

Even before signing the contract, I had realized that I wouldn't earn much money on such a niche book. Under the contract, the author is supposed to get a prepayment against future fee and the book is considered to be successful if the publishing house just gets back the prepayment. But I went for this project not for money. I went for it for two reasons.

First of all, for the experience itself. Although at work my main (and only) language is English, and different technical documentation I regularly write would be equivalent to a separate book, the authorship of a full 200-page book not in a native language is a great, complicated challenge.

Secondly, one of my tasks for 2016 was to write a book about DevOps. By august 2016, I hadn't even started it, so the proposal from Packt looked like a hint from the universe.

This was a funny, interesting and useful experience. I don't know when I repeat it again. Still, the process takes a lot, that's why other projects suffer (mkdev, for example). But something tells me that Getting Started with Terraform is not the last and even not the second to last book written by me.

Further reading