Writing the VDI Design Guide: Why, What and How?

If you haven’t noticed it, check this post. Since early August, the VDI Design Guide is available in the Amazon bookstore. Writing a book isn’t something you should take lightly, that’s what I experienced myself in the last 12 months. But why? And what challenges did I face? Would I do it all over again? And what would I do differently? I would like to answer these and more questions in this blog post.

Let’s start with a theme from the book: Why?

Why would you spend most of your free time writing a book instead of just writing some blogs and spending the rest of the time with your family? The answer to that question isn’t that simple. There are actually multiple answers to that question.

The first one would be that I really like to share knowledge, which of course can be done through my blog, but holding a book and read about something you are really interested in, is something different. Especially people born in the eighties may have used IT books to help them gain knowledge, which was the same for me. I still remember the big MetaFrame Design book by Brian Madden which helped me through deployments.

The second reason for putting so much time into something like this is that I get a lot of energy from bigger projects like this, but also from my VCDX project. Working on such a big project that has a lot of dependencies and requires you to gain knowledge about certain topics is why I wake up in the morning.

The last reason, which is also heavily described in the book, is my personal ambition to help aspiring VCDX-DTMs to take away boundaries and bumps in the road. Since I passed the certification in 2016, only 2 more joined the team. That’s not enough to keep the certification alive and appealing for people to achieve.

What about all of my own bumps in the road?

Let me be clear: I love challenges. Without challenges, life would be boring. In terms of writing a book, those challenges helped me to understand the process and stay sharp and focussed.

These are some of the things that came across while working on the book:

Scheduling writing time next-to a full-time job is hard. Discipline is the keyword here. And celebrating a deadline that has been met on a Thursday night with lots of beer is a bad plan (since the hangover avoids proper thinking and writing the days after).
Not creating backups on a regular basis can help you write the same section all over again in case of a “disaster”. A wise lesson here: Dropbox isn’t a backup solution (if versioning isn’t available). Having a proper solution that creates a backup of everything you do is essential. I used a time capsule and copied the latest file to a flash drive at the end of every week.
Microsoft Word for Mac sometimes does really weird stuff and crashes quite often. Forgetting to save documents every 10 minutes can give you lots of headaches.
Asking people to review works better if you set a deadline for the review and ask people to review just a section instead of the whole book (as this quite often is at the end of the whole process, just before your own deadline has to be met). Start reviewing as soon as possible, this will save you time in the end.
The people of CreateSpace are really helpful, but if they are really busy with review requests, they could possibly exceed the 24 hours that are normal for reviews (which isn’t a guaranteed review time).
Finalizing the book in just one week is quite undoable. I scheduled 4 weeks to finalize everything, which was a bit short as well. But as VMworld was approaching very quickly, I wanted to make sure the book was available in the bookstore, which (including shipping) could take up to 3 weeks.
Don’t overdo stuff. Writing 10 sections which are really good is better than 15 sections that are mediocre. I had enough raw content to write maybe 10 additional sections, but you need to work towards a final deadline, which can be hard.
Find out who is going to be your audience before you start writing. Having a mix of deep dive content and snorkel sections is not going to help the reader, at all.

How did I manage to get the book finalized in time?

The cool answer would be that I took the DeLorean back to the future and wrote the whole thing in just a couple of days (more about that very soon :))

The obvious answer here is again discipline but also support from my (ITQ) family and (community) friends). I have gathered some statistics in the past weeks that may give an idea of the process and related things.

It took me 12 months and 13 days from writing down the first words until the book was ready to be ordered.
The book contains a large number of words, but since the Dutch podcast Login TechCast will give away a book for the person who guesses (or comes the closest to) the total number of words, I will give the exact number in a couple of weeks.
To stay focused, I drank about 430 cups of espresso and cappuccino.

I have been listening to Spotify for almost 900 hours. Frank Denneman’s EDM playlist was responsible for almost 400 of those hours. This is the list:

4 pairs of AA batteries were used to charge my Apple wireless keyboard and 2 pairs for the trackpad.
I had 44 official draft versions of the book before the final version was released.
There were 5 deadlines in which I rewarded myself with a physical proof copy if I met the deadline. The deadlines were all 2 weeks prior to a VMware event so it was easy to meet them (since I wanted to take a physical proof copy with me to show when presenting).
Early 2018, I replaced my trusty MacBook Pro 13 inch 2014 model with a MacBook 12 inch. This was due to the mobility aspect of the 12 inch model. As I tend to travel a lot (both for work as well as with my wife), I have been writing in 12 countries (The Netherlands, Belgium, Germany, France, Denmark, Sweden, New Zealand, China, The United States, Switzerland Spain and The United Kingdom).

I hope this post gave you an idea of what it took to write the VDI Design Guide from a non-content perspective. If you have any questions about the process or something else? Drop me a message on twitter