What writing is? Telepathy, of course
— Stephen King
I wrote a full-fledged book with Manning Publishing with my name on it: Grokking Concurrency. Now, I'd like to share the journey of how it came to be.
TLDR
If you're toying with the idea of writing a book, consider these:
- How much work will this be? A ton. Like, an elephant-sized amount of work.
- How long will it take? Longer than waiting for your favorite TV series to release a new season.
- Am I QUALIFIED? Probably. Do you think a cat questions its ability to nap?
- What will I gain? Tough to say. Maybe just a book, maybe a bit of fame, maybe a new hobby, sometimes nothing.
- How much will I get paid? Enough to maybe treat your friends to a fancy dinner. Once. Close friends.
- Can I handle criticism? It's like getting a haircut – necessary, but sometimes you might not like what you see in the mirror.
- Any regrets? Same as you would ask me if I regret eating that extra slice of pizza – a bit, maybe, but not really.
- Should I do this? Absolutely.
Background
I never saw myself as a writer. It felt too far off, something I couldn't quite reach. Yet, there was this compelling urge to create something meaningful with words. Perhaps that's why I gravitated towards software engineering, and eventually to blogging, though the idea of being a technical book author was still far-fetched.
My blog is my own little world. It is my personal fortress, my sanctuary where I can share whatever is on my mind, not worrying about what is trending. I don't care much for passing hype. Instead, I love diving deep into things that interest me and sharing my thoughts, even if they are non-original and boring.
One day, I wrote a blog post about asynchrony, and it got a lot of attention online. People started talking about it on platforms like HN. There were lots of technical questions and not many straightforward answers or good beginner books on the topic. That's what pushed me to write this book. It was raw, short, and, most likely, dumb but it felt necessary.
Then, Michael Stevens from Manning Publications got in touch.
The Idea
In 2021, Michael Stevens from Manning Publishing proposed turning my blog posts and my book draft into a full-fledged book with a real publisher. This was unexpected.
My initial focus, mainly on asynchrony in Python, evolved into a broader concept of concurrency. So that it is not tied to any specific programming language but is a fundamental concept in modern software engineering.
During brainstorming sessions with Mike, we crafted the book's concept: beginner-friendly yet rich in theoretical foundations, peppered with practical examples. The book found its place in Manning's well-known Grokking series.
The Inspiration
Before I started writing the book, I thoroughly explored literature that inspired me, including:
- "Java Concurrency in Practice", widely recognized as a fundamental guide to multithreading in Java;
- "Seven Concurrency Models in Seven Weeks", covering various parallel programming models and offering a broad perspective on the subject;
- "Concurrency: The Works of Leslie Lamport", a compilation of works by one of the leading scholars in the field.
David Beazley's talks (who eventually wrote a review of my book!) also inspired me, check them out:
One of the main issues I wanted to address in the book was the often under-explained or overly academic presentation of nuances and details in concurrency. This created gaps in understanding and connecting concepts, making it hard to integrate these ideas into my own "coordinate system". You know that feeling, right?
The Proposal
For each concept I wanted to include in the book, I asked questions like, "How can this be understood?" and "What knowledge does the reader need to grasp this point?" This process of analysis led to the creation of the table of contents (ToC), which was also subject to doubts and revisions throughout the writing of each chapter.
The next step was to develop a proposal for the book, including a questionnaire and a rough outline.
Examples from the questionnaire:
Looking back, the initial proposal seems a bit naive and not quite like the book we eventually created. But that's not surprising, I guess.
The Book Writing Process
Writing a book involves a structured process with several phases.
Phase 1: Drafting Each Chapter
The first phase involved drafting each chapter, defining content, goals, examples, and the required reader knowledge level. This set the foundation for interactions with the Development Editor (DE) and deadlines for initial drafts.
Phase 2: Development
This stage focused on meeting deadlines and producing quality text. Sometimes I extended deadlines by a few weeks to enhance or rewrite the content, as preferred by my DE over incomplete drafts.
Phase 3: Review and Feedback
Each chapter underwent comprehensive reviewing, involving both my DE and a Technical Development Editor(TDE). DE evaluated the style, consistency of material, and examples, while TDE checked the technical accuracy of the text and code. Reviews sometimes led to revisiting and rewriting chapters to achieve high quality.
Phase 4: MEAP
After completing a third of the book, it moved into Manning's Early Access Program (MEAP), where chapters became available to readers in PDF and LiveBook formats. Readers could leave feedback, which helped improve the book. From this point onwards, the workload increased as new reviews and suggestions for improving the material came in.
Phase 5: Production
The production phase was the most mysterious and unpredictable for me due to a lack of transparency and clear timelines. This stage included final editing, formatting, indexing, and design, transforming the manuscript into a book ready for publication. Initially, it was planned to take about three months, but in practice, it stretched to six months due to various delays and adjustments.
Manuscript Writing
I often describe creating the book writing as just the tip of the iceberg. The toughest and most labor-intensive part for me wasn't the initial writing, but the relentless process of editing and refining the text.
Each chapter was read and rewritten from start to finish about ten times, and presenting what I called the "final" version always came with a mix of anticipation and anxiety. The final draft was always not final, as I often found myself making changes and adjustments the next day. Can you imagine yourself reading, writing, and re-writing the same thing over and over again? It felt like nothing changed and everything changed each and every single time.
Examples
Finding easy-to-grasp yet practical "concrete" examples was challenging. Coming from an academic background, where everything is taught, described, or explained in abstract terms, I struggled to devise concrete, understandable scenarios to engage readers. My examples seemed either too simple to be interesting or too complex to be explained well. My editors were patient and taught me a lot during the process and eventually, I was satisfied (am I?) with the examples I used, and it seems they resonated well with readers.
Many stories described in the book were taken from real life – from a trip to Hawaii and parallel adventures with laundry to cooking chicken soup and fighting for the last beer in the fridge. Each of these real-life scenarios was transformed and reflected in the pages of the book. Some stories came from my editors, while others seemed almost predicted, like the "pizza server" example.
Illustrations
'And what is the use of a book, thought Alice, without pictures or conversation?'
— Lewis Carroll
The illustrations? Oh, that was all Kate, my wife. She's the artist behind the scenes. We decided to not rely on an external illustrator who needs to be involved in the process and onboarded.
Our process was simple: I'd come up with some wild idea, probably something that made sense only in my head, then we fight, compromise, and then Kate would somehow turn that chaos into actual, beautiful artwork.
Code in the Book
The writing process included several iterations of rewriting code. The main task was to make the code understandable even for readers unfamiliar with Python. My approach was to present the code not as a set of complex constructs, but as pseudocode accessible to all readers, regardless of their technical background.
Although many code snippets could have been written more efficiently and more Pythonic, my primary goal was not to showcase my programming skills but to ensure understanding and accessibility of the code for a broad audience.
Review process
Manning has a thorough review process. Editors review each chapter as it is written, providing feedback and suggestions for editing.
In addition, there are three external reviews, one for each completed third of the book. Manning sends the book out to about a dozen technically competent reviewers who are not affiliated with Manning and may or may not be familiar with the book's subject matter. The reviewers rate the quality of the explanations, illustrations, topics covered, writing style, programming, and more. Many reviewers gave detailed recommendations beyond simple answers to questions. They were also asked to rate the book in its current state using an Amazon-like star system.
As for the reviews, they were polar opposites. About half of the reviewers found the book too easy and the other half found it too difficult. Half wanted more math and to fill in the gaps and missing pieces, and the other half preferred less math and more everyday examples. I can't say it was much of a help for me, but there were a couple people who really helped with their advice.
Feedback from Readers
Manning utilizes a browser-based book reading program called LiveBook, which allows readers to engage with and provide feedback on books during their development. This interaction was incredibly valuable, as it allowed me to improve the book with the help of my readers. For example, they would point out typos or request more detailed explanations of certain topics. Also, I got a lot of positive feedback along the way which was encouraging to me.
However, as an author, I encountered some challenges with LiveBook's interface for interaction. The tool's delayed email notifications, difficulty in locating specific reader conversations, and an overall clunky user experience made it somewhat cumbersome to use.
Manning
Let's set the scene first. Manning Publications, like other tech publishers, I guess, works specifically with engineers to create books. That's a comforting thought. Technical book authors aren't expected to be seasoned writers. And Manning doesn't expect them to be.
Manning went all out to guide me through the process. I worked with a bunch of editors and reviewers - copy editors, technical editors, reviewers with years of experience, and some without any. Looking back, I never had to worry about whether the book made sense or was readable. If I muddled up explaining a topic, I'd definitely hear about it. And if I got a basic concept wrong, a more experienced technical reviewer would raise an eyebrow and go, "Hmm, are you sure?"
Mostly, I was in charge of my own time and was never really pushed, but I imagine the experience might be different for other writers.
Overall, it was good to remember that making and selling technical books is what this company does. As long as I worked with them and listened to their advice, the chances of success were much higher.
Contract
The contract, unsurprisingly, was heavily in Manning's favor.
They own the content, no ifs, ands, or buts about it. This seems to be the standard deal, and I was okay with it this time around.
Also, Manning has the right to pull the plug at any point (up until the book is published), and if they do, you have to return your advance. In return, you get to keep what you've written so far.
The contract also had deadlines. I missed a few, but Manning didn't make a fuss about it. I guess as long as they believe in you and your book, it's all good. (But don't quote me on that).
The rest was just legal jargon designed to protect Manning, and I never really worried about it. As long as you play your part in the process, I don't think there's much else to worry about.
Money
First things first: writing should be more about self-expression than making big bucks.
In the world of writing, especially compared to IT, the money isn't quite as plentiful. So, stressing over genre popularity or sales volume might not be worth your while. Writing is primarily about creativity and finding a way to express yourself.
The advance was $5,000, with half paid out after completing the first third of the book and the other half upon completion.
I earn 10% on all the book sales. Royalties for technical books are typically around 10%. From my research, this seemed standard and expected. John Resig wrote that most technical books don't sell more than 4,000 copies. So you can do the math.
In a nutshell, don't expect a hefty payout. If your motivation for taking on years of weekend work is money, this might not be the project for you.
Marketing
When it comes to marketing the book, don't expect publishers to go all out. Unless you're working with a big-name publisher like O'Reilly that can send you to conferences and promotions, most tech publishers stick to a pretty simple plan: send free books to influencers and cross your fingers in the hope that they'll blog about it. The rest is up to you: write blog articles, interact with your followers, and do what you can to spread the word.
Takeaways
Don't do it for the money. Writing technical books isn't about making a fortune. It's about career growth and/or personal satisfaction. The odds of your book being a bestseller are slim. The real rewards are experience, prestige, and opportunities. You'll be a star in interviews, you could charge more for consulting, pick better clients, or even get an easier deal on your next book contract.
Writing a book takes a lot of time, If you're in a relationship, having a supportive partner is crucial.
I got tired of writing after about four chapters. Imagine how many times I thought about quitting – every evening and weekend spent pondering over concepts, word choices, and examples. The writing felt like torture, and now I get why many writers turn to less... healthy coping mechanisms - drinking, burning their manuscripts, etc. Creative people probably do run a greater risk of alcoholism and addiction than those in some other jobs, but so what?
Working with a recognized publisher like Manning was satisfying in itself. The process of writing the book with them was a huge lesson for me. Some writing tips I picked up along the way: Write as if you're talking to a friend; don't over-complicate explanations; get to the point; avoid fancy words; be ruthless in editing.
Support
You might think I've been doing all this work solo. But that's not the case. Honestly, I doubt I could've achieved anything without the help and moral support from my friends and readers. A big thank you to everyone who helped!
You Can Support Too
Want to lend a hand? You can! You can support by:
- Spreading the news on social media
- Writing reviews (on Amazon, Goodreads, or whatever people use nowadays)
- Mentioning to your colleagues, neighbors, and pets
Every bit of support, whether it's a kind word, a review, or sharing the book with others, truly means the world to an author.
Buy
me a coffee