MY BOOK IS OUT!!! 📚

It was mid-spring, and I was on my way from the university to my internship. I was in software development for a little over 6 months and by that time I had become more or less useful to my employer. We were working on an Android app called Piano Companion—my first real programming experience, let alone native Android (and this was 2015-2016, still Java, still XML layouts 😁). While commuting, I read a book my boss had recently recommended. "Refactoring" by Martin Fowler transformed my developer mindset, literally dividing it into before and after. You see, before I thought that if my code compiled without me struggling with it for hours, then that code was already amazing. I mean, it worked! But, as Martin Fowler famously said: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” From that day on, I decided to become a good programmer.

https://martinfowler.com/books/refactoring.html

After that, I've read many classical and staple computer science books, such as "Clean Code," "Clean Architecture," "The Pragmatic Programmer," and many more. I don't remember all of the details, obviously, but I know for sure that those books made me a much better software engineer. Not an Android developer, not a Flutter developer, but generally a software engineer. At the risk of sounding cheesy (which I absolutely intend to do), books have generally made me a better person and continue to do so. Yes, I'm that rare Pokémon who still prefers reading to watching, and yes, I'm aware the internet exists—I even pay for access! Since reading these books, it was my dream to once write one of my own, and I knew that one day I would do it, but I didn't know when exactly.

Then one day, I received a message. Jaime texted that he was starting to work on a book about Flutter design patterns and was looking for a co-author. He liked my article and thought it would be a great collaboration. Of course, I was interested, and that's how our work with Packt began. I had no idea what it was like to write a book, so many things were new and unexpected for me. I learned so much on this journey. So, let me lift the curtain for you 😁

The first surprising thing for me was that before signing the contract, you need to propose the full book outline—including all chapter names, headings, descriptions, and even page count. When writing articles, I always begin with an outline, but it's usually very rough and serves just as a guide. The final text readers see is often completely different. With the book, however, it's much stricter. At first, I thought this was ridiculous—the book will change so much during the process, so why be so specific upfront? In the end, I was grateful we did it. It helped us stay focused and understand where we were and what we needed to do. Of course, there were adjustments, but that was fine.

Adjustments 😅

Before working on the outline, we needed to understand our goal and target audience—the why and for whom we were writing. We decided that our main target audience was developers who had already tried some Flutter, built an app or two, and now wanted to level up and scale their skills. Both Jaime and I worked in mobile app agencies at the time and had a similar vision of patterns and approaches that work, so this was easy to agree on. Of course, this vision is based on vast experience, but it's still important to remember that there's always a huge degree of subjectivity. In the end, it IS our vision of how things should be done, NOT the only vision.

The description on Amazon

We structured the book into four parts: creating efficient UIs, connecting UI with business logic, structuring the model layer, and ensuring app quality. Here's how the final version of the book turned out:

Part 1: Building Delightful User Interfaces

1. Best Practices for Building UIs with Flutter

2. Responsive UIs for All Devices

Part 2: Connecting UI with Business Logic

3. Vanilla State Management

4. State Management Patterns and Their Implementations

5. Creating Consistent Navigation

Part 3: Exploring Practical Design Patterns and Architecture Best Practices

6. The Responsible Repository Pattern

7. Implementing the Inversion of Control Principle

8. Ensuring Scalability and Maintainability with Layered Architecture

9. Mastering Concurrent Programming in Dart

10. A Bridge to the Native Side of Development

Part 4: Ensuring App Quality and Stability

11. Unit Tests, Widget Tests, and Mocking Dependencies

12. Static Code Analysis and Debugging Tools

The broader vision for the book wasn't to teach a single "right way" to do things. Instead, it aimed to help readers understand the origins of design patterns and best practices, how to apply them, when to use them (and when not to), what to consider when working on solutions, how to align patterns with Flutter's framework, and how to approach app architecture holistically. Our goal was to empower readers to make informed decisions, rather than blindly following others' practices. We wanted them to grasp the reasoning behind these decisions and develop their own decision-making skills. While tech books often become outdated even before publication—due to the ever-evolving nature of software—we hope that even if specific practices become obsolete, the underlying principles will remain relevant. That's the real lesson we want readers to take away.

Of course, since we're talking about building apps, we needed to build some apps 😅 One approach in technical books is to make chapters independent, allowing them to be read in any order. This often means examples between chapters are unrelated. That’s not the approach we chose. We decided it would make more sense to build an app throughout the entire book, with each chapter building upon the previous one, ultimately resulting in a fully functional sample app.

The initial plan was to split the chapters equally among us. This plan didn't work out because, well, life happens. At some point, Esra also joined us. Long story short, I ended up writing chapters 1, 3, 4, 7, 8, 9, 10, and 12. And no, I didn't write them in exactly that order 😅

All of my first drafts were written in Notion 🤪 I have my whole life in that app 😂

Now, let's dive into the fun part: writing chapters. Today, I won't discuss my specific approach to writing, but rather the process from the publisher's perspective. Before a chapter is ready for the final book, it goes through several stages:

1. First, you write the preliminary draft.

2. This draft is then sent to an editor for review. The editor checks various aspects, primarily focusing on language, consistency, and adherence to Packt's practices. This process may involve several iterations, especially at the beginning when you're getting accustomed to the style. It's also during this step that a plagiarism check is performed.

3. Once the draft passes the editorial review, it's sent to a tech reviewer, who examines the chapter's technical content. In my case, this reviewer was hired by Packt, and their feedback was invaluable. I also sent some of my chapters to friends for additional review. When you spend so much time writing texts that only one or two people see, your mind can play tricks on you, and I wanted extra validation. These reviews were extremely helpful too! Thank you, Anna Leushchenko, Cagatay Ulusoy, Dmitry Zhifarsky, Tair Rzayev, and Ahmed Fathy for your contributions!

4. After the chapter passes this stage and is accepted, it becomes a final draft. At this point, no major content-related changes will be added to the chapter.

5. The final phase of editing the actual text is copy editing. I did find myself reverting a couple of changes made by the copy editor where they altered the meaning of what I wanted to say, but overall, this was the quickest step.

6. All of the code in the book is available in a connected repository. A dedicated person ensures everything compiles, works as expected, and is organized according to the book.

7. The next and final stage is when you actually see how the chapter will look in the book. Each individual chapter is laid out as a PDF and sent to the author for approval. This is also the step when you proofread and fix any typos or errors that slipped through. For me, this mostly involved restructuring code snippets to fit the book format and remain readable. I found many code snippets to be poorly formatted simply because of how many symbols can fit on one line of the book. Unfortunately, I couldn't catch this during the writing phase, as we write in MS Word (I have a lot to say about it, and these are not positive things 😂). We use Packt's template for styling things such as bold, italic, code, headings, etc., so they get automatically laid out in PDF, but that's about it.

8. Then all of the chapters are combined into the final PDF, and you proofread that again 😁

9. And finally, it can go to publishing!

10. Besides all of this, there are many other tasks, of course, such as writing the preface, front matter, registering on Amazon, marketing, and so on.

Technically, these are not even all of the steps 😅

From initial contact to final publication, the process took 1.5 years. Could it have been faster? Absolutely. According to our original deadlines, it should have been. But there are plans, and then there's life—and life gets in the way. A LOT.

Writing a book demands commitment, discipline, sacrifices, and an enormous desire to see it completed and published. In fact, I believe it's this desire that makes everything else possible.

I can't count how many times my dear husband heard, "I need to do a book thing," but it was infinitely more than he would have liked 😂

There were also countless moments when I secretly wanted to quit. Times when I thought if I read one more definition of MVVM, I'd lose my mind. Moments when I questioned everything I thought I knew. It would have been much harder to accomplish this without all of the support, belief, and patience I had from my loved ones.

I’m with Marques on that one

Besides feeling extremely excited that my work will finally see the world and relieved that I can step away from such a long-term and emotional project, I also feel nervous. Will my readers find the book useful? Will it help them make better decisions about app development? Are my explanations clear enough? Did I manage to get my ideas through? And so on. Of course, there will be many opinions, and I’m open to hearing all of them. But if even one young developer shifts their mindset after reading this book, I’ll be happy. So yeah. Look, Mum, I’m an author! 🥹

I also want to say huge thanks to my wonderful co-authors Esra Kadah and Jaime Blasco, and the whole team at Packt who made this project possible. It was a great experience working with such a professional team!

This project means a lot to me. There are many things I would do differently now, knowing what I know now, but this experience made my dream come true. I only wish my grandmothers were here to see it—they were always so proud of me. One of them was still alive when I started the book. She didn't care that it was about programming; what astonished her was that it was in English.

Ironically, this newsletter began as a way for me to write something other than the book, and now I'm finally writing about its publication. I definitely plan to continue writing and have many ambitious ideas in mind, so let's stay in touch 😛

P.S. If you haven’t yet, now it’s time to get your copy (Amazon or Packt) and later let me know what you think 😁💙

Top #1 & #3 new release in Object-Oriented design today 😁

Talk to you on Twitter!

-Daria 💙