It's been, again, a while since my last post here on DEV. In between posts, I've been rather busy with all kinds of projects. By far the largest of these is a book on CSS Grid. It'll be released soon and you can get a paperback or ebook copy over on Amazon.
Of course, this post is also meant to promote the book a bit, otherwise I wouldn't have posted it in #showdev, but I'd like to focus on the process of how this behemoth of a project came to be in the first place and what it took to get it out there. I also want to inspire people with this post. I want to show you how I worked on this and the necessary steps to complete it. A look behind the curtain, so to speak.
As a little disclaimer: This story is written from memory, but it shows the process nevertheless.
About the book itself
So, what did I actually write about? The title "Mastering CSS Grid" pretty much explains it: CSS Grid. I wrote about the basics and advanced CSS Grid rules, such as grid templates, responsiveness and nested grids.
The book also contains parts about design best practices, grid alternatives, and how CSS Grid and Flexbox play together. A chapter about different frameworks, such as Bootstrap, Tailwind, Tachyons and many more, shows how different popular frameworks understand grids and how they can be used to achieve default use cases, such as the "header-sidebar-content-footer" layout. The last chapter is a comprehensive cheat sheet and quick reference for all of CSS Grid and all related topics discussed in the book.
If you want to order the book as either an ebook or a paperback, if you want to keep it on your desk, you can find it here!
How it started
My writing career started a few years ago on DEV. I first wanted to find a bit of a nieche to write about, but didn't get the traction I originally expected. I then settled on writing about all kinds of things tech, mostly what I'm good at, sometimes learning a lot myself while writing. I wanted to have fun writing, and boy oh boy, do I still have fun doing it. And, in my opinion, that's what it's all about: Having fun, growing and helping others grow, too.
At some point in time, precisely in August 2022, I got lucky. Like, very lucky. I received an email of someone at Packt. They said that they've read my articles and found them "insightful and impressive" and that they were currently looking for authors, specifically for a book about CSS Grid. I would've been foolish to deny that offer.
And so I accepted.
My personal first lesson: Don't try, just do it. I never had the goal to "attract a publisher" and start working on a book. Of course, writing a book was a long-term goal of mine, but my writing on DEV wasn't meant to lead to that. I did what I liked, the rest came around eventually. Of course, a great bit of luck is involved, but writing is a skill one can train, learning in the open is a great thing to do anyways, and once a sufficient skill level and audience is achieved, publishers will notice.
Baby steps
The first step wasn't even the contract. It was an outline. The folks at Packt provided me with a template, describing the target group, a list of chapters, what topics each chapter would cover, what the reader will learn and what benefits they would gave once they've read the chapter. They had a very specific idea of topics in mind and wanted to make sure that the outline would cover all of these at least somehow.
The chapter names and rough section titles for each chapter, of course, were drafts. We wanted to make sure to have at least some idea of what this book will look like in the end.
Afterwards came the organisational part. They proposed a contract, which we both signed. I got introduced to the project manager, the editor, and many more people of the team. These people then introduced me to the tools we would use.
After that, I started writing.
My second learning: Do not underestimate the organisational effort of such a project. There is a reason that book publishing companies are successful and exist since basically the invention of the printing press. These people are experts. They know about steps in the process we non-publishers don't even know we don't know.
Getting sober
And I immediately started writing on the wrong part of the book. I started with the foreword, including it in chapter 1. I thought that, logically, this would be the first part of the book, so it should be written first, right?
Wrong.
The reader should "hit the ground running" with CSS Grid. However, the people at Packt were understanding. They told me to keep the draft for a later stage of the project. So, after the first bit of frustration, I understood their intention: The reader may have already read the foreword and would want to finally learn something.
After I completed the first draft of chapter 1, I eagerly awaited the feedback, expecting a few comments at maximum. But then I opened word and saw dozens of comments. They were devastating at first. Some examples:
- "Please elaborate here."
- "What do you mean with this?"
- "Incomplete sentence, did you mean [...]?"
- "Please introduce this figure first, then include the figure, then explain the figure."
- "Don't use words such as above or below, as locations may very well be off after editing in the print version."
I sobered up. And I was frustrated. The editor added that they first needed to accustom to my style of writing, but that it was otherwise a very solid start. I can only imagine what a non-solid start would've looked like.
My third learning: Even if there is a lot of critique, it only shows the potential. I started writing the book with a certain mindset and many assumptions about the process. I've never written a book before and deliberately wanted to dive into it head-first. Of course I would first run into a wall. But the publsiher is there to help, dunk on the author. After all, they are as interested in the quality and success of this book as I am, so why should they mean any harm? Of course, the critique is frustrating and demoralizing, but that's the ego talking. It should be seen as an opportunity to grow. Thinking back to my studies, the people proofreading my thesis told me that dozens and dozens of comments are the absolute norm, not a sign that the work is of bad quality. And that's true.
A lot of progress
After sobering up, discussing some concepts (such as how to deal with figures), having a call or two with the team and working further, I got into a flow.
I handed in each chapter individually, as a MS Word document. Word, even though I personally prefer markdown, has the advantage of allowing for comments and very clear visual formatting.
The people at Packt gave me some very sophisticated templates to work with. Bold text would not only be bold, but also magenta, code blocks would be monospaced and have a bright blue as their background colour, callouts and editor notes were in bright signal colours. Even though these formats irritaed me at first, because why would anyone print it this way, I quickly noticed that these tools also help me to gain an overview and that they also helped the layout team to understand how they should format the content.
I had a deadline for each chapter. Once I received the chapter, I had a deadline to incoporate feedback. Once I received the tech reviews, I had fixed deadlines to incoporate their feedback. Once I worked on the final drafts, I had deadlines for incoporate their feedbacks.
Deadlines help. Especially when working on a creative project. I encountered writer's block more than once, but I had to find ways to counteract it, otherwise I would not meet the deadline. The feedback cycles got shorter, the comments got less and less and at some point, we all got into a flow. And progress was made.
My fourth learning: Find ways to get into a flow, embrace the flow and work on maintaining it. You'll get better at writing. Dividing the project into smaller sub-projects helps a lot and deadlines make you keep yourself from overengineering.
The final steps
The tech review was a huge milestone. The folks at Packt found two amazing experts to work on the entire book and give their feedback. They found details that I would've never seen, simply because they were not nearly as deep in this project as I was. The additional pairs of eyes were basically an asynchronous version of duck debugging.
At this point, I want to shout out to
Giuseppe Caruso and Michelle Manemann (ordered alphabetically) for their hard work. Without them, we wouldn't have reached the quality level we have reached in the end.
Given, incorportaing their feedback was hard. I had to restructure many sections, replace many figures and add a ton of stuff, but in the end, it was worth the effort.
The final drafts of all chapters had a total of a dozen comments in the end, we had to replace a few images because the platform refused them (something about illegible text on some screenshots), but the polishing phase did not take much from my end.
And with this, we were done.
My fifth learning: Do not underestimate the help of people that don't know what you've been writing about. Get in a fresh pair of eyes every now and again to help with details. They will find things you would've never noticed.
The aftermath
The book is done. What more is there? Well, as it turns out, a lot: Posts like these, for example.
I asked in my company if people would like a free ebook in exchange for an Amazon review. I still want to polish a thing or two in the official GitHub repository (mainly add some comments, but alas). I want to promote the work myself, get it out to people. There may be a second edition, a third one, fourth or fifth.
My sixth learning: Just because the bulk of the work is done doesn't mean that you'll never hear back from it. I'm constantly checking on my social media posts, tracking how many impressions they got. I check the Amazon best seller ranks to see how it's doing in pre-sales. I can't wait to hold it in my hands. Even though I'm finished, the best is yet to come.
In conclusion
Writing a book is a lot of work. It took me many of my weekends, many of my free afternoons and, sometimes, frustrated me to the point that I just wanted to give up. I invested a lot, and so did the publisher team at Packt. We've all contributed to this.
And this is my seventh learning: Writing a book is not something a single person does. Even though their name is written on the cover. It is a group effort. And I'm forever thankful for having this opportunity. It fulfills a live-long dream.
And please excuse the occasional typo, wrong comma or whatever you may find. I've done my share of editing for a few weeks. :D
I hope you enjoyed reading this article as much as I enjoyed writing it! If so, leave a ❤️! I write tech articles in my free time and like to drink coffee every once in a while.
If you want to support my efforts, you can offer me a coffee ☕ or follow me on Twitter 🐦! You can also support me directly via Paypal!
Top comments (18)
Congratulations, and thanks for sharing the journey!
260+ pages sounds a lot (I saw that number on one of your tweets). Was there a target length when you started, or was it more a case of writing as much as possible for each of the topics?
Thank you so much!
That's a great question! Yes, there was. The publisher originally expected around 250 pages, which turned out to be more in the end. I think more than that would've been very hard, since there's only ever so much you can write about without watering down the content and actually losing focus. I could've added more about the history of grids, polyfills, design aspects, etc., but then it would've been less of a tutorial book for the technology itself. Less than 250 would mean that I woujld have had to condense the content, losing the opportunity to explain details.
With the index, foreword, glossary and additional content about related books, the final product has 330 pages total, however, the 260+ pages of actual content felt like a very sensible choice.
When creating the outline, I had to give estimations about how many pages each chapter would roughly fill and we double-checked that the sum was roughly 250. Especially after the tech review, I had to expand the explanations on some aspects, which resulted in some extra pages, totalling at around 263 in the end.
Does that answer your question?
Yes thanks. Just two more questions please 😊
You mentioned not using words like above and below. How did you get around that?
Was the page target for wall-to-wall text, or did it account for layout, paragraph spacing, and diagrams too?
Sorry for bombarding you with questions; I'd just like to learn more about the process.
Don't be sorry, wanting to learn is never a bad thing and I love answering all your questions! 😀
"Following" and "previous" are good substitutes. So, instead of talking about the "above figure", I would write "the previous figure", or mention the figure number directly, i.e. "As shown in figure 3.14". My own mind is usually very focussed on locality when it comes to ordering information, so it took me a bit to adjust to that, but once I got used to this technique, it worked fine. I recently read a papeback book that did not follow that approach and I immediately noticed why using "above" and "below" doesn't work. If the formatting is just slightly different in the final product than it is in the draft, you might end up having "the above figure" as the first line of a page on the left (assuming LTR writing), meaning there is no "above" or "left" at all. "Previous", on the other hand, circumvents that.
While writing, I used MS Word only, so I added section titles, paragraph spacings, figures, code examples etc. in there directly. The page target included these, so what counted was the actual page count of the Word documents. Figures also transport information, although in a different format, so counting them is sensible. Code examples, especially with comments, allow the reader to understand what is going on by being able to look at actual examples of things being used, which is yet another way of conveying information. I think the publisher used page targets to get a sense of how large the end product will be. A word count of, say 10k words (roughly 20 pages, according to A Popular Search Engine™) may produce a wildly different page count if there are a lot of figures vs when there are no figures at all. A page count keeps things manageable.
I hope this answered your questions, is there anything else you want to know? ☺️
Thanks for the detailed info. Just one more thing please: it sounds like it was quite hectic - especially towards the end. How did you find time for everything, especially with a full-time job? Did you have to set aside strict time blocks for writing?
You're very welcome!
You're right, it was quite hectic at times and sometimes I struggled to meet the deadlines. We didn't rush it, though, and usually the project manager and editor were very understanding if I had good reasons for not meeting a deadline, such as falling ill (I caught a nasty flu halfway through), family business or holidays.
I tried to stick to a rhythm, spending one to two hours per day writing. I would use train rides and other idle time to work on the project, too. I tried getting up really early for a few weeks, work on the book before breakfast and then work on my job. That worked surprisingly well, especially since I did not have to write for two hours after already working for eight.
Sometimes I had to spend the weekend, though, working for some four to eight hours per day, but I think that was a necessary sacrifice that I was more than willing to make. Handing in a large chapter I was happy with, gave me a feeling of achievement, and that was usually enough to compensate for not being able to play video games that day lol. Luckily my partner was very supportive and had my back in crunch times. Don't underestimate the support you get from loved ones during such a project. Helping each other thrive can strengthen the bond so much.
Is there anything else you want to know? I'm happy to answer all your questions! 😊
I think that's about it (for now 😁).
Thanks again for the detailed answers, and best of luck!
Congrats. Just added to my wish list. By the preview it appears to be a good read. Thanks for putting out a paperback. I hate to say it, the older I get, I find myself going back to books over videos and PDFs when trying to learn or broaden my understanding of topics.
Thank you so much! I personally also prefer paperback. There's nothing like the smell of a freshly printed book 🤣 The only thing I really miss about paperbacks is Ctrl+F, but that's what ebooks are for, right?
I hope you enjoy the book and that it helps you learn some new things! 😊
Book just arrived. I'm a couple chapters in and great so far. Technical but not hard to follow. So far, exactly what I need. Working on any other books? I could definitely use a good JavaScript book from you.
Lovely article @thormeier , it gave me the same sense of passion about our job that I felt while I was reviewing the book.
Passion always brings excellence. And yours is an excellent book on a topic that is fundamental in modern CSS development.
Thanks again for sharing the huge effort of writing a book, that’s very insightful and shows us, as always, that knowledgeable people are the most humble, and, most importantly, that ”no man is an island”.
It was fun, instructive, and an honor to review it, keep up with the great job.
Thank you so much, Giuseppe! I did work on this book with a lot of passion and reading your reviews, I noticed the passion in your work too!
I personally think this is the most important lesson for me: Such projects are not single-person jobs. Although there are people that write ebooks alone, do the editing, publish them themselves, take over all of the promotion, and whatnot, but it takes a ton of effort and a ton of knowledge to do so. I'm deeply impressed by the people that manage it, though! For me, having an amazing team of experts helps to ensure quality with every single step of the process and it allows people to focus on what they do best.
I'll do my best to keep up the quality, but I think I'll take a few weeks off from large projects like these. 😅
Hey, congratulations 🎉🎉🎉
I've always enjoyed reading your blogs, so I know the book is going to be great as well!!!
Thank you so much! I hope so, too 😅
Thanks you for sharing!
It may be the next book, one never knows enough 😁
You're very welcome! I hope you enjoy it and can learn something new from it if you decide to get yourself a copy. 🙂
Congratulations on completing your CSS Grid book! 🎉 I'm excited to explore the insightful content you've created. Thank you for sharing your journey and inspiring others. 👏
Thank you so much! I hope you like it and that it helps you learn new things. :)