This content originally appeared on DEV Community and was authored by Pascal Thormeier
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
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!
This content originally appeared on DEV Community and was authored by Pascal Thormeier
Pascal Thormeier | Sciencx (2023-05-20T16:10:47+00:00) I wrote a book on CSS Grid – Here’s how! 📖💡. Retrieved from https://www.scien.cx/2023/05/20/i-wrote-a-book-on-css-grid-heres-how-%f0%9f%93%96%f0%9f%92%a1/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.