Learnings of writing Groovy in Action, Second Edition

More than two years ago, I wrote about the effort to revive Groovy in Action. Little did I know that it would take another 2 years of a huge combined effort to get the book out. Maybe not surprising for other authors, and it has been mentioned many times before, but yet; it was an effort. It was quite a time-consuming process to write a book, coordinate with your co-authors, the editors and the publisher, while also keeping in touch with you, the reader, who come up with a lot of greats ideas and publish errata on the forums.

But, having mentioned the effort, it’s such a rewarding effort to finally have finalised the book! If feels like I can finally check one the things on my bucket list, and that is to have my name on the cover of an amazing book. And while I’m very biased, I’m pretty sure this is not only the best on Groovy, it’s also a great book on learning how to program. Topic like functional programming, using collections, testing your software, and more advanced topics like ASTs, creating DSLs, etc are all covered in the book, and provide a great help for beginners in programming as well as advanced software developers.

While writing the book, I’ve learned a lot. Not only about the Groovy programming language, and how to convey our message to our audience, but also about the writing process and the technologies used to write the book. For example, we are using GitHub to store the book, which is a perfect way of keeping track who worked on what, restore versions, etc. However, the book is written in Word. Which is probably the single most horrible way to write a book in. Don’t ever do this! Instead, choose a more open format like AsciiDoc, which is a text document format for writing notes, documentation, articles, books, ebooks, and much more. AsciiDoc can easily generate EPubs and PDFs, while writing in plain text, which is an ideal format for Git. Find a publisher which supports plain text publishing, and preferably AsciiDoc!

Secondly, writing with a (distributed!) team of software developers, who all have limited time due to their family life and their 40 hour workweek, is hard. Coordinating, keeping a focus, it’s hard. When you embark on such an adventure, do a brainstorm session. Create a backlog, keep track of who is working on what, and find a good way of communicating with your team members. Gitter might be such an option, or Google hangout, but in reality, nothing beats being together and having a face to face talk about the progress of your book. It’s not absolutely mandatory, but it helps quite a lots.

Thirdly; keep a focus while keeping the pace. Quality matters a lot, but so does delivering. The first version of Groovy in Action covered Groovy 1.0. The Second Edition originally covered 1.8, but then Groovy 1.9 came out. And then 2.0. So we had to check all the code examples, which, fortunately (and I can really recommend doing so) could be executed automatically. In the end, Groovy 2.4 was covered, which is great for the community, since it being the most recent version of Groovy, but tough on your writing crew. And mostly thanks to the endless energy of Paul King, you can now all enjoy the hard work we’ve put into the 912 pages of Groovy code.

While there are many more things to learn from such an experience, the three lessons above proved to be the most important for me. And while many things could have been done much better, in the end, it’s the results that matter, and difficult roads often lead to beautiful destinations. I think that I speak for the whole Groovy in Action team while I say that we are proud of the result, and we’ve produced a quality product for you to enjoy. I’m proud to have been able to produce such a book, and to have been given the trust of our publisher as well as our audience to deliver the quality you expect us to deliver. I thank you for your patience and your support in delivering this book. We couldn’t have done it without you! Thanks!