Update: Almost two years later, I've finally finished the book! You can purchase Ansible for DevOps on LeanPub, Amazon, or iTunes.
For the past year, I've seen many accounts of first-time authors finally taking the plunge and self-publishing a book on some technology or another, and finally decided to do the same.
Like many of these first-time authors, I felt I was prepared for the project, for the following reasons:
- I had (what I thought was) a fairly deep knowledge of the topic I was writing about.
- I've been writing both short and long-form articles for a few blogs and smaller publications for many years.
- I'm used to the process of writing and refining my writing.
- I can usually articulate technical topics in a readable manner for a wide audience.
Almost a full month has passed since I started writing my first technical book, and I've finally reached a point where I am ready to publish the fledgling book, Ansible for DevOps. It's only been one month, but I already have many ideas to share with others who may be interested in pursuing a book writing project. These ideas may also persuade—or even dissuade—me from future book ideas!
Writing a blog ≠ writing a book
I've heard this before, but I didn't really understand it until I got into the meat of the book. Writing for a blog, you normally work with small, distinct topics. Organization isn't usually important, and you can find a rhythm to keep up the writing on a regular schedule. Because of the potential variety, struggling to continue writing isn't typically a big problem.
When writing a book—one that's not simply a compilation of a bunch of loosly-related blog posts—everything has context. It doesn't make the grunt work involved in putting words on the page much different, but it does require more discipline. You have to organize your thoughts, order them in a logical manner, and constantly refactor. It can also be boring at times, when completing a section you've been writing for days.
While blog-compilation books can be informative, I wouldn't deem them technical or instructional books. Rather, a technical book aims to teach a topic methodically, beginning with foundational knowledge and slowly building on top of it. Imagine if a builder threw piles of bricks everywhere, and laid parts of the foundation here and there throughout the project—the end result is a bit of a jumbled mess (like many blog-compiled books). Lots of good content, but no real foundation or organization to build upon and guide the reader.
I intentionally avoided incorporating any prior work (from my blogs or documentation) in this book, and I think it's made the book more coherent (so far). I've even made a point to avoid reading the official Ansible documentation while writing about certain topics, to make sure I'm writing in my own style, not simply repeating what others have written. Afterwards, if a topic needs more clarity, I'll refine based on the official documentation or on other prior examples.
Write about something in which you have a deep interest
I really enjoy using Ansible. It's one of the few software projects in recent years that I was able to pick up in a day, and it keeps suprising me with simple but flexible features every time I start working in a new area. I've used Chef and Puppet a little before, and saw the value they provided, but never actually enjoyed using them.
If I were writing a book about Puppet, I guarantee I wouldn't be going the extra mile to make sure code worked well, and my writing was relevant and concise. I would more likely drone on about topics I've seen discussed elsewhere, and my book would look more like a documentation rewrite than a well-structured guide that leads the reader to a deeper understanding of the subject.
This seems to be the situation with many technical books I've read; the author (or authors) were simply contracted to write a technical book on some piece of software, and they cranked out a book. That kind of writing isn't as effective in helping readers grow their understanding of the subject. I enjoy books that were written with opinion, with passion. I'll remember what's these books better than impersonal books written on contract or by an impassive author.
Writing forces you to know your subject matter more deeply
I knew this intellectually, but didn't really understand how little I really knew about Ansible until writing the book. Even a young tool like Ansible has a very deep set of features, and I really didn't get to see the depth until I started writing the book and refining the examples.
In one short month, I've gained a much fuller understanding of Ansible and grown in my knowledge of Linux system administration and application deployment. Don't get me wrong—I've done a lot of work with continuous integration, shell scripting, deployments, etc.—but the depth of knowledge I've gained from constantly researching and revising my writing for this project is a great asset.
If I do something once, I don't really understand it. If I do it again, I might know more about what I did, but I still don't really understand it. If I teach others about it (in writing or teaching), I force myself to understand it so (a) I don't look like a fool, and (b) I'm don't waste other people's time. Just like a master's student defending his thesis, I feel like I'm better able to explain things once I've written about them.
I don't call myself an Ansible expert by any means—I've had enough experience to know I am very much a beginner in infrastructure administration—but I am well on my way due to this writing experience.
Publishing a book takes time and patience
Before starting the book, I thought I could crank out a book in a few months. Even if I weren't interested in polishing the book by submitting it to a good technical editor, this is far from reality.
As I'm writing the book entirely outside of my full-time job, I know I can't sustain as rapid a clip as I have for the past month. I've been writing as often as I have free time, sometimes writing for half an hour in the morning before work, then for one or two hours at night. The key is consistency. If I give myself a target of five hundred words per day, I can usually hit that target. On a few weekends, I was able to write a few thousand.
Writing a good book requires a lot of discipline. I wouldn't attempt writing a book about a subject in which I had only mildly interest (see the points above!).
'Lean' publishing gives you a major advantage
I can't imagine writing a book without a service like LeanPub. Not only does LeanPub remove pretty much all hassle from the publishing process, it lets me focus on the one part of the process I can do well: writing.
I've been writing in Markdown for the past few years, so the ability to write the entire book in LeanPub-flavored Markdown was a major bonus (apparently people used to write and/or lay out books in Microsoft Word!). Being able to click a 'Preview' button and see the end result was immensely helpful in sorting out layout and formatting issues early. It saves time refactoring if you know how to format things well the first time!
The final selling point of LeanPub is that it enables lean writing. Especially when writing about ever-improving software, like Ansible, it is great to be able to change content to reflect new features, and keep the book up-to-date as I write it (rather than comb through everything for a second edition after the fact).
I'm looking forward to the feedback (both positive and negative) I'll get now that people can start reading through the book-in-progress. I hope it will help make this book a great resource for those working with Ansible.
Conclusion
It feels great to have finished over one third of my first book, and I don't think I ever would've started without a platform like LeanPub. The process of writing a book is already difficult—it helps to be able to follow the same methodology I follow in software development when publishing my work: publish early, and publish often.
Are you interested in server and infrastructure management with Ansible? Buy Ansible for DevOps for a discounted price while it is still being written, you'll still get the full book free, once it's complete.
Post written by Jeff Geerling, owner of Server Check.in.