writing

Finished writing my first book, Ansible for DevOps

After almost two years of writing, editing, and rewriting my book, I've finally completed the first edition of Ansible for DevOps, and it's available for sale on Amazon, LeanPub, and iTunes!

Ansible for DevOps cover - book on Ansible by Jeff Geerling

The book is 400 pages long, just shy of 80,000 words, and was a huge effort. It's such a relief to finally have it 'out the door', though publishing-as-I-write has been a great experience. Pre-first-edition, I've already sold over 2,200 copies of Ansible for DevOps on LeanPub!

Here are a few blog posts from Server Check.in where I describe more of the publication process:

$25K in book sales, and I'm almost ready to publish

I started writing my first book almost two years ago. At the beginning of the project, I set an ambitious goal: Write a 90-page introductory-level technical book on some relatively new software, and sell 200 copies.

As a developer and dabbling entrepreneur, I calculated that if I sold the book for around $10-20, and wrote the book based on real-world scenarios I'd already encountered (meaning very little extra research/discovery required), I could make enough money to keep things interesting while helping a few hundred developers pick up the new software more quickly.

Almost two years later, Ansible for DevOps is almost 400 pages long and has sold over 2,000 copies—and I haven't yet published the book.

Books sold per month

What follows is an analysis of what led to this success, and some cautions for those considering writing a book.

Writing on LeanPub - $0.21 per word

I've been blogging for 10 years, and I've written over 800,000 words in posts. As time progresses, I try to clearly convey more information with fewer words. It's been hard to quantify the value derived from those words, however, since the only measurements I could make (e.g. a small amount of ad revenue) have been subjective at best.

For almost seven months, I've been writing Ansible for DevOps, publishing on LeanPub as I write. In that time, I've written ~41,600 words (with roughly 60% of the book complete), and have had ~800 readers purchase the book (either standalone, or in a bundle).

Self-Publishing a Book (on Ansible)

I've published the first portion of a book I've been writing, Ansible for DevOps. This is my first-ever book, and I've written a little about the process of writing on Server Check.in's blog: Self-publishing my first technical book on LeanPub.

Ansible for DevOps cover image

I'm excited about the early feedback I've already received—and I haven't even finished writing half the book! I'm hoping to finish the first complete draft of the book (and continue publishing it in stages on LeanPub) by summer 2014.

Self-publishing my first technical book on LeanPub

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:

Photography book – thoughts and questions

I recently told my Facebook friends that I was thinking of writing a book to help people get better photos with their fancy cameras, and received a lot of positive feedback.

Jansen Baby Birthday
Getting consistently sharp, vivid, interesting photos doesn't have to be hard.

Some of the things I want to write about include:

  • Getting photos that aren't too bright or too dark.
  • Getting photos where people aren't blurry.
  • Making people look great.
  • Taking pictures that are beautiful, more often.

I don't want to be technical in this book, other than introducing people, slowly, to important concepts in photography. I want to show people through example and experience exactly what's going on when they snap a picture that they later find to be ugly, horrible, or too blurry or bright/dark to use.

Old Mac of the Month - Macintosh IIci (on 512 Pixels)

This month, my old Mac story about a IIci was featured on on the excellent Apple-related blog 512 Pixels, by Stephen Hackett: Old Mac of the Month: Macintosh IIci.

My old Mac IIci

I briefly mention the IIci in my (not-yet-complete) Computing History article here on Life is a Prayer.com. I really liked the IIci, and it's probably one of my favorite Macs of all time, especially considering I probably owned and used it the longest!

Special thanks to my brother and dad, who not only helped me get into electronics and computing, but also helped me edit the article.

Inspiration and Garbage

My relationship with writing is a funny thing; I've never been a 'writer', per-se, but I do love writing things from time to time. I probably write about as much prose as the average active blogger, but a lot of my writing never sees the light of day, nor is it focused in one particular area.

I blog about Drupal development and technology over on my Midwestern Mac blog, about the Church and technology on my Open Source Catholic blog, about life in general here, and about a variety of other things on various other blogs and fora.

But I think it's really important for someone who is serious about writing—and writing well—to do two things:

  1. Stay inspired
  2. Throw out the garbage

These two actions support and help each other; discarding mediocre writing projects and posts will allow you to take a fresh look at what you're writing, while staying inspired can help you more easily discern what's garbage, and what can be engaging and/or informative.

On Writing Documentation

I've been slowly reading through "Coders at Work," an excellent book in which Peter Siebel interviews many different programmers on their work and craft, and I hit a great little snippet of advice from Peter Norvig:

"The overall design of what's going to do what, that's really important to lay out first. It's got to be something that everybody understands and it's also got to be the right choice."

Basically, before you start doing some huge project, have a bit of a meta discussion about what you're trying to do. Document the process / steps, make sure it makes sense, and code to that process. You don't need to necessarily comment on every little tidbit of code you write—code should be somewhat self-explanatory if written well—but you should at least document what your functions do, and what kind of idea you're trying to implement.

Plus, if you document beforehand, you'll be able to conform code to documentation, and at the end you'll have a framework of your docs already complete!