Writing a book is a daunting task, especially when it's about a technical topic like API testing with Karate. This is my journey from the first empty page to the finished book which officially launched today!

What? A book?

I never seriously thought about writing a book. During my career, I had written quite some blog posts and two magazine articles but never something too extensive and in-depth. So it came quite as a surprise when I was approached by Packt Publishing to talk about a potential project.

Unfortunately, I was not the right person for what they had in mind. I won't disclose the initial topic here. Let's just say that I didn't have enough knowledge or practice with this subject. I turned this down but took the chance to pitch something else that I was actively working with and had experience in: writing a book on Karate API testing.

This was a rather spontaneous idea, because we have been using this testing framework in our company for some time and I gradually gained more and more knowledge about it. Also, I noticed that there was no literature about it yet, only the official online documentation, a lot of Stack Overflow posts and occasional Tweets showcasing some functionality.

It's getting more serious.

The first step for me was to fill out a document detailing the concept of the book, its chapters, key learnings and potential audience. Based on this document, Packt started researching about the Karate framework, its distribution and the state of literature around it. When they came back with their findings, it took some more video calls to finalise the contract, some more conversation with HR to get the necessary permission for a sideline activity and, of course, to my family. After all, they would have to deal with me not being available for quite a while.

The toughest part about this initial document was the estimation of the needed number of pages for each chapter. What I later found out was that this number is not just an arbitrary placeholder but it is expected that the chapters roughly adhere to these numbers. This is also called out by reviewers and if there is a larger deviation from it, you need to be prepared to explain why this is. You are always free to make changes to the structure of the book if you have good reasons for it. This happened multiple times throughout the writing process as the overarching theme, tone and breakdown of the book becomes clearer.

Procrastination vs Deadlines

I am a procrastinator. When I tell people this, often times they are quite surprised since I usually get stuff done. The thing is that this often times happens at the last second. This is why the contract I finally received from Packt looked very scary at first as there were very tight deadlines set for every phase of the writing process. For each chapter, there is a clear date for the deliverables, when the...