How time passes! It seems only yesterday I was publishing my first book, after starting it in a completely unplanned manner. Yet that was 2016, and we’re in 2019 now.
3 years later, I published my third book, “Hands-on Functional Programming with C++”, and my first book written with a publisher. Once again, I feel compelled to write about the process, for one simple reason: I want you to write a book as well, and I believe you can do it.
The story is simple: I helped organize the CppEurope conference at Mozaic Works, where I gave a talk about functional programming in C++. I published my slides on Slideshare, only to find a few months later an email from one of the Packt Publishing editors, offering me the opportunity to write a book on the topic. I liked the guy, loved the idea of exploring functional programming in more detail, and was interested in seeing what I can learn from a professional publisher about the business.
Prologue: Initial feelings
Given my experience with self-publishing, I wasn’t afraid of the actual writing, despite the length of the book (350 pages or so). I knew I had enough to write about, and the source code takes space as well.
I was afraid however of being forced to do a lot of editing. The editor assured me it won’t be a problem and I’m happy to report it wasn’t. This is possible through the way the project is structured – but I’ll come to that later.
Finally, I was happy about one thing: someone else will market my book this time. While I know pretty much what needs to be done for book marketing, it’s a lot of work and it takes time. With my self-published books, I couldn’t do many of the activities, and I also made mistakes in the beginning. This time, I could learn from the marketing team.
Of course, the downside of working with a publisher is that you give away your rights for the content. Still, I felt that in this case the learning and the support provided by Packt Publishing was worth it – and I’m happy with the decision I made. Plus, they offered a good deal, not bad if you want just to write and get some money for as long as the book sells. I would take this deal again, one more time, and then review how it pans out.
Going back to the process, it all started with the outline and the pitch.
Part I: The Outline
The first thing my editor asked of me is to fill in a pretty detailed outline. Now, I’ve written before of how I hate planning as a writer and how I wrote my first book pretty much out of nowhere. I was a bit reluctant to fill in the outline, but it turned out to be very helpful later on.
The outline consists of:
- the names and a short description of the parts that form the book
- the names of chapters from each part
- a short description and a list of headings for each chapter
As far as I understood, the outline serves two goals. First, it helps the editor pitch the book to the editorial team. Second, it serves as a basis for a book plan.
We’ll see next how this helped me. Once the pitch was accepted, some feedback received, the outline slightly improved, we moved to the next phase.
Part II: Writing the Book
A book editor was assigned to me; it turned out to be a brilliant cooperation.
We started working together. I would write the chapter, announce her when the draft was done, she would read it and comment, then I made some final changes and that concluded each chapter. We were moving along according to the deadlines set for each chapter in the book plan, and it all worked quite well for a while.
Then, the winter holidays came and I couldn’t keep the schedule anymore. Afterwards, a combination of work and life factors delayed the schedule even more. We managed to regroup in the last months, and I finished the book.
This is where the outline and the book plan was useful. I’m a big fan of Eisenhower’s quote “Plans are useless, but planning is essential”; while I don’t like planning, it’s proven useful again and again in my activity and my life. We had to reshuffle the plan, yes, but we had the chapter descriptions to work with. This plan allowed my editor to give me the push I needed to complete the book.
So, how did the editor helped me with the content?
Part III: Things I Learned from My Editor
We all have our own writing style. I favor writing the minimum text that provides the information, and I pay a lot of attention to the flow of the phrase and of the sections. I care about the reader experience, and optimize for it. And I use simple words because I feel that’s how I can reach the most people and explain complex notions simply.
But, it turns out, I also forget to do a few things. The most important one is to close a point before moving to the next. These transitional sentences are very useful for readers, and my editor was extremely helpful in pointing them out to me. While writing this sentence, I realize that the previous section wasn’t closed perfectly; the transition is too sudden. A better transition would be: “I mentioned above that the book editor and I made a great team. That wasn’t limited to the schedule; she also helped me improve my writing style. Let’s see how”.
I still need to practice this skill to get better at it. For now, let’s see what I did right.
Part IV: Things that Helped Me Immensely
Writing a book is not an easy task, and even though I love it, there are many things that can go wrong. With this book, a few things helped immensely.
The first one is deadlines. I’m not a fan of deadlines, but I was impressed by the positive pressure they had on me. No matter how much I like the topic or how much I like to write, there are times when I would waste time, procrastinate, or lose interest in the topic at hand. Whenever this happened, I just had to look at the deadline to convince myself to start writing. Once I started, it felt good, which allowed me to finish or at least to advance. I also believe this worked because of external pressure; my editor kept reminding me about my deadlines which sounds annoying but it was really quite helpful. So, experiment with deadlines – who knows, they might work for you as well.
The second thing I did that worked really well is writing tests for my code samples. Every piece of code that I wrote is covered with tests, which meant that I was certain the code works. At the end of the writing process, a technical editor started looking at my code to check that it works, that it’s well written and that it fits the content. When he couldn’t run a few of the samples, I could immediately point him towards the need to install a newer compiler; I was dead certain that the code worked properly. This may not sound like much, but the last thing we needed in the final days before publishing the book was to fiddle around debugging code samples and copy/pasting them again into the book content at the right places. I saved a ton of work by making sure the code worked properly. So, write tests!
A few other things helped me. I knew the topic quite well. I have practiced writing for more than 30 years now. I practiced writing clean code for at least 15 years. I think a lot about software design and development practices. Most importantly, I was curious to learn more about functional programming.
Conclusion
Writing a book can be hard, but given the proper support, the right tools, and a topic that you like, you can publish your own book. If you’re self-publishing, writing a detailed outline and setting out deadlines for yourself might help you. If you write a technical book, writing tests will save you a lot of time and worry. Also, I wouldn’t discount working with a publisher; the support they provide can be very helpful as it turned out to be for me; even if you give away your rights, it may be useful to learn the process from a professional organization.
About the Book
The book is “Hands-on Functional Programming with C++”, it is available on Amazon as an ebook and hardcopy. It’s a practical guide for functional programming written by a programmer for programmers. It’s easy and fun to read, it doesn’t talk about math and after reading it you’ll be able to brag to your colleagues that you know how to use functional programming.
That’s not all though. You’ll learn about Test Driven Development, function-centric design, property-based testing and a few design patterns specific to functional programming. Buy it, and don’t forget to leave a review for other potential buyers. Thank you for your interest and your support!
