Origins

We were in July 2024. It was a warm weekend, and I was lying in bed thinking about my next “big thing”. A few years earlier, I had finished writing my book. It was an exhausting experience, but I finally felt ready for another challenge.

All of a sudden, I got an idea. What if I launched… a podcast?

I jumped out of bed, searched for a book on podcasts, bought one, and started reading about all that needs to be known: the different formats, how to find an audience, whether we should invite guests, and so on.

I even had the perfect name. As a lover of the cozy atmosphere of coffee shops, I wanted my podcast to reflect that same warm ambience.

The name would be The Coder Cafe.

But a few days later, the excitement faded. Did I really want to make a podcast after all? I had a few concepts in mind, but none of them truly clicked. Eventually, I decided to drop the idea.

Yet the name The Coder Cafe stuck with me. I checked thecoder.cafe domain, and it was available. Every great story starts with a domain name. Let’s buy it!

Now I had a domain name, but I still didn’t know what to do about it.

Around that time, I started reading a lot of newsletters. One in particular inspired me for the quality and regularity of its content: by
.

I even launched one called Go Engineer, which I quickly stopped. Thanks to my book, I already had a Go audience. But deep down, I didn’t want to write only about Go anymore. I didn’t want to be tied to a single language when there are so many areas I’m passionate about: code health, testing, distributed systems, reliability, observability, performance, and more.

At some point, the two ideas converged. I would create a newsletter, and it would be called The Coder Cafe. It wouldn’t be tied to one language. It would be a place where any software engineer could find something useful.

I already had experience with online writing. My Medium blog had more than 4k followers. But since my book, I hadn’t really written there. I needed a fresh start and a chance to relearn how to write online. Writing a book and writing online are two very different activities. So I ditched my book on podcasts and bought another one: The Art and Business of Online Writing.

If you don’t know this book, I really recommend it. Two principles in particular stuck with me:

1. Volume matters. The most popular blogs and newsletters publish often.

2. Timeless topics matter. Daily news about which stock to buy has volume but no staying power. Timeless content always wins.

These two ideas would shape my newsletter: I wanted to write daily (volume) and focus on fundamental concepts (timeless).

I started drafting the newsletter description:

At first, I planned to publish five posts per week on different topics. But after talking with my girlfriend, she suggested I group posts by theme. For example, one week on caching, another on testing, etc. I loved the idea. She also recommended writing a recap post at the end of the week as a way to reinforce learning. I loved this idea even more. I wasn’t sure people wanted to read my content during the weekend, though, so I refined the plan:

• Four posts from Monday to Thursday, each on one core concept.

• A recap on Friday, to reinforce the week’s lessons.

By mid-August, the concept was finalized. It was time to write some posts find a good logo!

The Quest for the Right Logo

I bought a paid subscription to Canva and spent my whole weekend creating different logo variations:

None of them really convinced me, though. When I was about to design yet another version, this time of a logo that repeats inside itself a few times to hint at recursion, I suddenly became aware of my lack of artistic skills. I decided to delegate the work, heading to Fiverr to find a freelancer.

That’s how I met a very talented artist, Eli Huynh. She even worked on the Attack on Titan anime, can you believe it? I asked her to craft a coffee shop logo, and I slipped in some personal touches I wanted to see hidden in the design:

• An illustration of Designing Data-Intensive Applications by , my favorite computer science book.

• Moby Dock, the Docker mascot (I worked at Docker and loved my time there!)

• A Docker command on the coffee machine.

She produced this beautiful masterpiece:

I shared it with different people, and the feedback was unanimous: the drawing was stunning, but… it was not really a logo. Nothing against the artist, obviously, I was the one giving the requirements, but indeed, it wasn’t a logo.

So I moved this illustration to the About page and kept searching for another freelancer. After a few failures, I started working with someone who feels promising. His first attempt was the following:

After many back-and-forths, we converged on this version:

When I received it, I loved it instantly. The colors felt warm and cozy. It captured the atmosphere I had in mind. Sometimes you don’t need outside validation, you just know. This logo would be The Coder Cafe’s identity.

In the end, I spent dozens of hours on this logo quest. You might think it was absurd, especially since I still hadn’t written a single post. But for me, visual identity had to come first. It’s like opening a restaurant: before designing the menu, you work on the atmosphere and decoration. Is it really absurd? I don’t think so.

The same applied to the tagline. I tried dozens of variations:

• One daily concept.

• Learn daily, grow deeply.

• A timeless concept with your coffee.

• Brewed daily.

• Etc.

Eventually, I chose this one: One concept with your coffee. It captures exactly what I want: concepts, a cozy coffee-shop vibe, and a short, memorable line that feels right at home in The Coder Cafe1.

Paid?

Yes, initially, my idea was to create a paid newsletter. I even shared it with an ex-colleague who gave me blunt feedback:

From the outside, it may sound harsh, but I didn’t take it negatively. It actually made me reflect.

Why did I want to create a paid newsletter in the first place?

One of the things I enjoy most in life is learning and teaching (whether through writing, speaking, or any other format). If I could one day make a living from these two activities, that would be a dream job. It’s that simple.

I didn’t create The Coder Cafe because I needed more money (of course, Google pays well). I made it because, in my dreams, it could eventually become my main activity.

So, starting as a paid newsletter felt natural at the time. It was my way of committing fully to the project and testing whether The Coder Cafe could be more than just a side experiment.

Launch

By the end of August, it was time to start creating content.

Publishing one post a day is a lot. I did not want to feel pressured every evening to write for the next day, so I decided to build a buffer of posts. Throughout September, I wrote 25 posts plus their recaps, enough for six weeks of content. That felt safe.

On October 7, 2024, The Coder Cafe newsletter was ready for launch, and its first post went live 🎉.

To organize free and paid content, my idea was simple. All posts during the first four weeks would be free. The goal was to build an audience and show that my writing was worth paying for. After that period, I would keep one post free per week and place the others behind a paywall. The free post would act as a sample for new readers.

The first week showed decent traction. I reached 120 free subscribers and 8 paid subscribers. The number of free subs was modest, but the paid-to-free ratio was good. Yet, to be honest, many of the early paid subscribers were friends or people who wanted to support me. Very few were convinced by the paid value proposition yet.

The second week was better. One post reached the front page of Hacker News and passed 25k views. In a single day, subscriptions jumped to 291 free and 11 paid. That is when I saw the real impact of Hacker News:

However, barely two weeks after launch, my girlfriend and I learned something that would have a massive impact on my daily newsletter: we were going to have a baby.

Balancing my job at Google, my girlfriend, some social life, and a daily newsletter was already challenging. With a newborn on the way, it became absolutely impossible.

Just one week after launch, I was the happiest man alive, but my daily newsletter concept was already dead.

Marketing

A quick pause to talk about marketing.

I’m not going to overwhelm you with my “massive” marketing campaign (aka one post on LinkedIn and one post on X).

But one day, I came up with a fun idea. What if I hid a coupon for lifetime access to the newsletter somewhere on thecoder.cafe website? Developers love puzzles. Maybe this could go viral?

I started by hiding a tiny URL in the illustration designed by Eli Huynh:

• When pasted in a browser, this URL pointed to a Gist containing some JavaScript code.

• Running the code displayed a Base64 string.

• Decoding it three times gave another URL.

• Visiting that link opened a blank page that printed yet another URL in the browser console.

• That new URL pointed to an SVG file of a blue circle.

• Opening the SVG’s source revealed a hidden message with a free coupon:

  <svg width="200" height="200" xmlns="http://www.w3.org/2000/svg">
    <desc>Congratulations! Email me at contact@thecoder.cafe with the title "f63dee1e".</desc>
    <circle cx="100" cy="100" r="50" fill="blue"/>
  </svg>

So, how many people found it?

None.

How many even reached the very first URL hidden in the image?

None.

Stopping The Coder Cafe?

So, I knew I would eventually have to stop publishing daily because I would run out of time. It broke my heart for one particular reason. With free subscribers, I can explore topics. If they do not like a post, they skip it. With paying subscribers, though, I felt accountable. People spend their own money on my content, and I cannot disappoint them. The daily newsletter was a contract between them and me, and I was about to break it.

In December, my buffer was shrinking fast, and I started to think seriously about stopping everything and refunding all paid subscriptions. Then something unexpected happened.

It was close to Christmas, and the post of the day was on TDD. I was at my parents’ home when I received an email notification: a new paid subscriber had joined. And not just anyone, himself. Funny enough, I was not even praising TDD. I said that while it makes sense in some contexts, I do not really use it.

A few days later, Kent left a comment on one of my posts:

Looking back, that comment changed everything for me. It gave me confidence in myself and in my writing. If someone like Kent Beck found value in what I was doing, then maybe there was something worth continuing.

Right after that, I took the bull by the horns and published a post titled Stepping Back to Move Forward. I explained that I would stop paid subscriptions, and I also pointed out a deeper issue with my daily format.

As I explained, each week had a theme, for example, unit tests. Due to limited writing time, the daily posts were not very long. Instead of writing one in-depth article, I split the topic into four posts. Since only one of them was free, that was the one I shared on platforms like Reddit. The feedback I got was often that it lacked depth.

I could have argued online: “But the depth is spread across four posts. If you read the whole series, you’ll see it. You just have to become a paid subscriber. Blah blah blah.”

Let’s be honest. Nobody would have cared. Readers judged the content they saw. If it looked shallow, they were right, period. This made it hard to attract new people, and apart from the post that went viral, most of my content stayed relatively anonymous.

One week later, I sent a private email to all paid subscribers. I explained I was stopping paid subscriptions and issuing refunds:

On January 3rd, I had 747 free subscribers and went from 15 to 0 paid. From that moment on, The Coder Cafe became about enjoying the writing without pressure to deliver and taking the time to delve more into each topic.

What Followed

In March, I decided to stop blogging on Medium and fully switch to Substack. I feel at home here. I also wondered what would happen if I wrote more personal reflections and stories rather than concepts. So, I created a new section called Lattes & Stories (this post is in this section). I really enjoy writing in a more storytelling style.

In April, I reached the 1,000 subscriber mark. To celebrate, I organized a coding challenge and gathered around $1,000 worth of prizes from Keychron, , JetBrains, and O’Reilly. Thanks again to the sponsors! It was a lot of fun to run. Maybe I will do another one later. $10,000 of prizes for 10,000 subs? We can still dream.

Also in April, the idea of building a community around The Coder Cafe started to emerge. I wanted to create a sense of belonging, where members feel that they matter to one another and to the group. So, I created a Discord server. I’m still exploring options to spark engagement.

Join the Discord community

In May, something surreal happened: , the very newsletter that inspired me, recommended The Coder Cafe2.

In September, I converted the content of year one into a 260-page book, available on Leanpub.

Also in September, I enabled sponsorships to explore partnerships with companies interested in supporting The Coder Cafe. If you would like to partner on a post, you can learn more here.

Some stats after one year:

• The Coder Cafe reached more than 3,600 subscribers across 119 countries.

  

• I wrote 78 posts and collected 309,432 views.

• Two posts stood out and together represent about one-third of total views:

  • So, I Wrote a Book: The Story Behind 100 Go Mistakes and How to Avoid Them. I started writing this as soon as I finished my book, but it took three years to get the perspective to complete it. This post has a special meaning for me.

  • Working on Complex Systems: What I Learned Working at Google. A deep dive into complex systems, written during a holiday with my brother in a city life retreat in the middle of Sweden. That trip also gave the post a special meaning.

    

Conclusion and Future

So, is The Coder Cafe a success story?

Financially, no. Because Stripe took fees on subscriptions, I refunded more than I received, so the balance is even negative 😅.

But in the end, after one year, money wasn’t the measure of success. Positive feedback, helping readers, and rediscovering the joy of sharing stuff mattered more. It also pushed me to explore many topics across tech and non-tech.

I haven’t let go of the dream of making this my living, just not yet. My priority now is reaching more people and building a stronger community. We will see where that journey leads.

A glimpse into the future. I will continue to write about concepts and occasionally share stories. I will also launch a new section where we will pick a system and build it from scratch, step by step, week after week. I am currently collaborating with a company to craft the content of the first series. I am looking forward to releasing it.

Speaking of collaboration, I would love to explore this aspect, whether it’s partnering with companies, inviting other writers3, or featuring people with a worthy story. We will see.

🫶 I love sharing, and you give me an audience. Thank you for that.

See you next week for a (long) post on CRDTs.

Teiva

Resources

More From the Lattes & Stories Section

• So, I Wrote a Book

• Why I Switched to Vim Keybindings

• What I Learned During My Paternity Leave

Sources

• The Art and Business of Online Writing

❤️ If you enjoyed this post, please hit the like button.

At Google, we get 18 weeks of paternity leave (yes, that’s amazing). Since the birth of my baby at the end of May, I’ve been out of the office and will be back at work next week. These months were the best time to spend with my newborn, but also a nice chance to read, learn, and try new things. Here are some of the technical and non-technical things I got into.

Technical Stuff

Code Health Guardian

I started reading Code Health Guardian. Let me jump straight: it’s one of the best books I’ve ever read on software engineering. Period.

Don’t be fooled by the use of “AI“ in the subtitle (“The Old-New Role of a Human Programmer in the AI Era”). The focus is on code health. It covers various topics such as complexity, causes of complexity, documentation, interfaces, code discoverability, and functional programming.

To me, it felt like a more modern (and better) version than Clean Code.

A quote that perfectly summarizes my love for this book:

I strongly recommend this book.

Systems Thinking

Learning Systems Thinking is a book about the concept of systems thinking.

What’s system thinking? Modern software is no longer just isolated applications; they are becoming systems of software. Systems thinking invites us to shift our perspective from focusing on a single software to looking at the larger system it belongs to, and how the parts interact.

One interesting idea in the book is the Iceberg model. It suggests that what we see (the events) is only the tip of the iceberg. Beneath the surface, there are patterns of behavior, deeper systemic structures, and even mental models that shape how the system works:

The lesson is that when working with systems, we should move from reacting to events to understanding the patterns and structures that create them, so we can design better long-term solutions.

The book was a good introduction. Yet, in retrospect, I would have liked it to give more concrete actions or applied examples. I will need to follow up with another resource to go deeper into practical applications of systems thinking.

NOTE: Have you read my post on complex systems? It’s the most-read post of The Coder Cafe.

Learning C++

During my leave, I started learning C++.

Why? At Google, many systems are developed in C++. One I’ve been involved with is Borg. Because I hadn’t done C/C++ since my studies, every pull request I made was painful. I wanted to improve that.

I started with A Tour of C++ by Bjarne Stroustrup. It’s refreshingly short for a C++ book (about 300 pages). That was my entry point. Let’s see what will come next1.

NOTE: Did you know that Google uses C++ without exceptions? Mostly for performance and maintainability reasons, functions return an absl::Status2, which is similar to Rust’s Result.

Whitepapers

At some point, I wanted to delve deeper into distributed systems, but I felt like I had already read most of the well-known books on the topic.

What I had completely missed until then was the angle of technical whitepapers. Most of them are more challenging to read than blog posts, but they offer a depth that can’t be matched.

I read a few during my leave, including F1: A Distributed SQL Database That Scales and Amazon DynamoDB: A Scalable, Predictably Performant, and Fully Managed NoSQL Database Service.

After my paternity leave, I plan to continue exploring more of them as they have become one of my favorite sources of technical insight.

For discovery, I used ‘s papershelf.

Non-Technical Stuff

The Mom Test

The Mom Test is a great book that explores patterns and anti-patterns when discussing business or product ideas with customers.

The core idea is this: if we pitch an idea to our mom, she will tell us it’s great, even if it’s not. Customers often do the same. They don’t want to hurt our feelings, so they give polite feedback instead of useful feedback.

The solution is to avoid asking opinion-based questions like “Do you think it’s a good idea?” Instead, we should ask about real experiences and behaviors, questions that even our mom couldn’t fake. For example:

• Bad:

  • “Would you buy a product which did X?”

  • “How much would you pay for X?”

• Good:

  • “How are you dealing with it now?”

  • “Why do you bother?”

  • “Talk me through the last time that happened.”

I haven’t run customer interviews myself, but I’ve participated in some. Interestingly enough, many of the anti-patterns from the book showed up in those meetings. This wasn’t a book with an immediate outcome for me, but it broadened my perspective, and that’s always valuable.

The Art of Explanation

The Art of Explanation is a book written by a BBC presenter and journalist. The author describes how to clearly explain any topics, focusing on ten main attributes:

1. Simplicity: Is this the simplest way we can say this?

2. Essential detail: What detail is essential to this explanation?

3. Complexity: If a topic is complex, we can’t dodge the complexities and hope to explain something well. It reminded me of this illustration:

   

4. Efficiency: Is this the most succinct way we can explain this?

5. Precision: Are we saying exactly what we want to communicate?

6. Context: Are we provided all the necessary context for people to understand the topic?

7. No distractions: Are there any verbal, written or visual distractions? (It reminded me of rule #9 here.)

8. Engaging: Are there times when it’s easy to lose focus? Lots of good things on how to maintain a good flow, such as making sure we move from one sentence to another logically.

9. Useful: Have we answered the questions that people may have?

10. Clarity of purpose: Above all else, what are we trying to explain?

The book gave me a practical checklist I can return to whenever I need to convey something complex. It was also a reminder that being clear isn’t a gift, it’s a skill worth practicing regularly.

Made to Stick

Made to Stick is a book that focuses on the question of why some ideas have a lasting impact while others don’t. The authors introduce their SUCCESs framework to make ideas stick:

• Simple: Find the core of an idea. The more we reduce the amount of information in an idea, the stickier it will be. I loved this line:

  When you say three things, you say nothing.

• Unexpected: A great way to catch attention is with a surprise. We can’t demand attention; we must attract it, and one of the easiest ways is to convey something unexpected by breaking an existing pattern.

• Concrete: Our brains are wired to remember concrete data.

• Credible: The more credible we are, the more an idea will stick.

• Emotions: A great way to make people care is to convey emotion, to make them feel something.

• Story: How can we make them feel something? Via stories and great storytelling.

Made to Stick helped me learn that ideas don’t just succeed because they are true; they also succeed because they are communicated in a way that people remember. I strongly recommend this book as well.

Building a Second Brain

Building a Second Brain was one of my favorite reads during this time. I loved it so much that I even wrote a dedicated post about it:

For me, this book was a real game-changer in how I capture and reuse what I learn.

Steal Like an Artist

Steal Like an Artist is a book on creativity built around a simple idea: nothing is completely original. As creators (writers, musicians, or anyone producing work), the author suggests we should “steal” from anything that inspires us and sparks our imagination.

I didn’t find this book as compelling as others, but it does offer a few useful insights. One that stuck with me is the difference between copying and creating: copying a single person is plagiarism, but drawing from many influences is what makes something feel original. The trick isn’t to imitate, it’s to transform and remix ideas until they become your own.

Four Thousand Weeks

Four Thousand Weeks is a productivity book, but with a very different take than most books on the topic. The title comes from the fact that our lifespan is roughly 4,000 weeks.

During my paternity leave, I felt overwhelmed at times by everything I wanted to read and do, and this book helped. Its message is simple: instead of trying to produce more and more, we should accept that our time is limited. We will never get everything done. What we can do is focus on the few things that matter most and give them our best attention.

It helped me find some peace and reminded me to focus on what matters most to me.

Fiction

Last but not least, I couldn’t spend this paternity leave without some science fiction and fantasy reading.

On the sci-fi side, I started exploring the Warhammer 40k universe by picking up a few books about the Night Lords faction. If all you know about Warhammer 40k is the painting and miniatures, you should also know there’s a massive, surprisingly coherent lore built around it. I always assumed it would be some cheap sci-fi, but I was wrong; it’s much richer than I expected.

On the fantasy side, I usually enjoy epic fantasy such as The Lord of the Rings or The Realm of the Elderlings. Yet, I wasn’t in the mood for long and heavy stories. I wanted something lighter and more relaxing. That’s how I found the “cozy fantasy” genre. I read with Legends & Lattes and The Spellshop. Nothing really epic happens in these books, but the atmosphere is calm and comforting. Perfect for a quiet morning coffee (after a tough night).

Being a Dad

Above all else, these four months were a great opportunity to spend a lot of time with my kid (thanks, Google, for that).

I’m not going to elaborate too much on how it went, as it’s very personal. The only thing I want to emphasize is how having a baby is one of those rare experiences in life. Let me explain:

• If we traveled to Japan and loved it, we could still say next year, "I’m going back to Japan again.”

• If we enjoyed a tlayuda, we could say this weekend, “I’m going to make some tlayudas again.”

• If we enjoyed that Coldplay concert, we could say, “Next album, I’m going to see them again.”

With a baby, things feel different. Experiences are truly unique because of how quickly they grow. Especially in the beginning, a baby changes day in, day out: a new way of looking at things, better head control, a new way to grab an object, etc. Because babies change so quickly, every experience becomes one of a kind. Tomorrow is already going to be a different day, a different experience.

But if we look beyond, we might even say that most experiences are truly unique:

• We might return to Japan, but we will notice new things, meet new people, or experience it differently.

• We might make tlayudas again, but they won’t taste exactly the same.

• We might see Coldplay again, but maybe we’re with a different person, in a different city, at a different point in our lives.

Being a dad brought me this truth: life itself is unrepeatable in its details. It is not inherently good or bad; it is simply what makes so many experiences unique and fatherhood so magical.

📚 Resources

More From the Lattes & Stories Section

• So, I Wrote a Book

• Why I Switched to Vim Keybindings

❤️ If you enjoyed the post, please consider giving it a like. It’s a helpful signal to decide what to write next.

💬 What have you learned in these past months? Anything you’d like to share?

Leave a comment

From the early days of my career, I used various IDEs but never spent much time memorizing keybindings.

Yet, in 2016, I switched to IntelliJ, and with that move, I decided that for once, I would work on my productivity and make sure to touch the mouse as little as possible. Good decision or not, I also decided to customize nearly 90% of the keybindings. It got to a point where someone familiar with IntelliJ wouldn’t even recognize my setup.

If you’ve ever gone through something like that, you know it takes time to be productive. At first, your brain melts for every single action. But after a few weeks, you start getting used to your config and can be really productive.

Everything was perfect for seven years as I kept working with IntelliJ until… I joined Google. Indeed, it was quite a shock for me to see that Google has its own IDE1.

There was a plugin to import IntelliJ’s default config, but since I had overridden almost everything, I had to reconfigure a ton of shortcuts manually. And even then, some keybindings I was using just didn’t exist in Google's IDE.

At this point, I decided to make one of the move I’m the happiest about: switching to Vim keybindings.

Let me just clarify what I mean by Vim keybindings. I didn’t switch to the Vim editor itself; I switched to Vim shortcuts. Indeed, many IDEs like IntelliJ or VS Code allow you to use Vim keybindings. For example, if you open this sandbox, it’s not the Vim editor, but it’s an editor based on Vim keybindings.

The learning curve was pretty steep, at least for me. Also, it’s worth noting that using Vim with a QWERTY keyboard layout is much more efficient than with other layouts. If you’re using a layout that’s quite different from QWERTY you may also need to switch layouts.

NOTE: When I joined Google, I switched to Vim keybindings and a new keyboard layout at the same time. I remember sharing my IDE with a colleague during one of my first days and judging by how slowly I was typing, I’m pretty sure he thought I was dumb.

So what are the benefits?

First, default Vim keybindings give you almost everything you need to be productive. Sure, there are still some IDE-specific features (like refactoring functions automatically), but most of what you need to navigate and manipulate code quickly is right there. It took me some time to adapt, but today, I can say I’m even faster than with my old customized IntelliJ setup.

Second, and probably the essence of this post: switching to Vim keybindings gave me a consistent editing experience. Whether I’m coding in Google IDE, on Google Colab, at home on IntelliJ (with the IdeaVim plugin), or editing a remote file through a terminal with Neovim, the experience is the same. I don’t need to adapt to a different setup every time. And if one day I switch to another IDE, chances are high that it will support Vim keybindings too, as the Vim community is really active.

Being efficient and keeping a consistent editing style across tools is why I would strongly recommend having a look at Vim keybindings. Maybe it’s not for you, and that’s perfectly fine. But if it clicks, it might give you the same productivity boost it gave me.

📚 Resources

More From the Lattes & Stories Section

• So, I Wrote a Book

• What I Learned During My Paternity Leave

Explore Further

• Practical Vim // The book I used to learn Vim. Most of what I know comes from it, and I highly recommend it if you decide to switch to Vim.

• My own Vim cheat sheet

• Vim Tips You Probably Never Heard of:

• IntelliJ 25% discount code on all product pack: TheCoderCafe. // This post is not sponsored by IntelliJ, but since they supported 1,000 Subscribers, 1 Coding Challenge! I thought it was fair to mention it since I talked about IntelliJ in this post.

❤️ If you made it this far and enjoyed the post, please consider giving it a like.

💬 Do you use Vim keybindings? If not, have you ever considered trying them?

Leave a comment

Hello! Today, I’m going to share the story of the process behind writing my book.

The Beginning of the Story

My book, 100 Go Mistakes and How to Avoid Them, was published in August 2022. But the story starts much earlier, back in 2018.

At this time, I was working in Switzerland, refactoring a C++ legacy codebase. Together with my colleague and friend Damien Chambon, we started evaluating Scala and Akka (an actor model framework) for a potential rewrite. Why Scala and Akka, you may wonder? Well, back then I had mostly Java/JVM experience, and I was intrigued by the promises of the actor model.

But things were… definitely not simple. First off, it was a whole new language to learn. Second, Akka is a beast. It takes time to ramp up, and we even had to hire an external consultant to help with the implementation. After months of work, we finally had our first PoC. And yet, neither my colleague nor I were really convinced.

So, we started looking at another language to counterbalance Scala. Maybe this new one wasn’t the sexiest language ever invented, but it looks promising, efficient, and much easier to ramp up with: Go.

After just a couple of weeks in Go, we were able to cover the same scope as our Scala/Akka PoC. And for me, that was the beginning of a love story with the Go programming language.

A few months passed, and I moved to another company and another country: the UK. I was back working in a Java ecosystem since my Go experience was still too limited to land a proper job. Plus, given the international move, the company itself mattered more to me than the tech stack.

That experience turned out to be horrendous. It was full of politics, and I hated every aspect of my job. But in the evenings, I kept working on personal projects in Go. After just three months, I decided to stop the bleeding and move on to another company.

This time, I was determined to get a Go job. It was May 2019. I signed to a new company, and finally, I could develop in Go all day long.

A Blog Post That Changes Everything

After four months in this new company, I noticed that some of my colleagues were making the same mistakes I made when I was working in Switzerland.

So, I decided to write a blog post listing common mistakes in Go called The Top 10 Most Common Mistakes I’ve Seen in Go Projects.

Let’s be honest: the title was way more ambitious than my actual experience. Reading it, you would expect someone with deep Go expertise, right? But the truth is, when I said “projects“, it meant:

• The PoC my colleague and I wrote in Go

• The four months I had spent at my new company

Nothing too crazy, really. I didn’t have big ambitions for the post, but I love writing, and I thought it might be interesting to share. So I published it on Medium.

Unexpectedly, the post became very popular: 4.7k claps, trending on r/golang, and even listed as one of the top articles of 2019 by Golang Weekly, the most well-known Go newsletter:

At this point, I’m starting to believe that writing about mistakes seems to interest people. So my train of thought was: let’s keep collecting mistakes and see how it goes. Perhaps at some point, I could write a GitHub repo that would contain all my findings?

16 Months of Work and a First Contact With Manning

Fast forward to November 2020. It had been 16 months since I published my blog post, and by then, I had collected 100 mistakes in Go. During that time, I gathered mistakes from various sources, mainly:

• At work (to be honest, I was also a significant source of inspiration!)

• In various studies and blog posts

• In different open-source projects

At this stage, I felt much more confident about my project. Sure, an open-source repository could be great, but I wondered: why not go for a book? Being someone who loves reading and writing, I had always dreamed of publishing my own.

I contacted only one publisher: Manning. Why Manning? Here’s what I wrote in my book:

Do I see Manning as a high-quality publisher? Absolutely. Is that the only reason why I contacted only Manning? Maybe not.

Back then, to propose an idea to O’Reilly (not sure if it has changed since), you had to fill out a document containing hundreds and hundreds of pages! OK, maybe my memory is playing tricks on me, and it was just a dozen pages, but I remember thinking: “This is too much effort.“

Whereas with Manning? A simple email was enough:

Something funny to highlight here. In this email, I was saying, “I’m at 80%” because for most of the mistakes, I already had some content written:

• The mistake itself

• A surrounding example

• And various solutions to fix the mistake

So, in my head, the hardest part was already done.

I haven’t been more wrong in my entire life.

The next day, I got a reply from someone at Manning with the title of acquisition editor. If you’re not familiar with that role, an acquisition editor is someone who evaluates and signs new book projects for publication. Basically, a scout. Throughout my writing journey, he was my main contact at Manning, and as you will see, he helped me at a critical moment later in the process.

We had a first meeting to briefly discuss my idea, and Manning was on board to move to the next step: filling out a proposal. This proposal was a document with 21 questions to frame the project, including things like:

• Speaking about yourself

• A summary of the book

• Describing your target reader

• A table of contents

This document was then sent by Manning to external reviewers, all with Go experience, who wrote their own evaluations of the proposal. Funny enough, my mate Valentin Deleplace, who would become my colleague a few years later, was actually the first reviewer of the book.

As a potential author, I had access to all the reviews. And while it’s obviously essential for a publisher to judge the technical quality of a project, it was also super valuable for me. It helped me see whether the idea only sounded good in my own head or if it could actually be interesting to others, too.

I received a total of seven reviews, and all of them were positive. Some included constructive feedback on how to improve certain aspects (like the table of contents, for example), but the overall tone was fully supportive.

It was December 7, 2020, roughly two weeks after I sent my first email, and I received an offer from Manning:

Contract

Let’s talk about one of the aspects people ask about the most: my contract.

In terms of royalties, I got paid 10% on all sales. On one hand, yes, that’s not a lot. Yet, you really have to understand how helpful a publisher can be for a first-time “author” with zero experience like I was back then, for two main reasons:

• First, and we will go over the process later, but the number of reviews from different people is insane. If I had written the book completely on my own, I can guarantee the quality would have been way lower.

• Second, in terms of visibility, going with a publisher helps a lot, especially if, like me back then, you had around 400 followers on Twitter. Sure, content can still go viral without a big audience, but it’s a lot less likely.

When I signed the contract, I also received an advance: $2,000 upfront, and $2,000 after delivering one-third of the book.

The contract also included deadlines:

• One-third of the book will be delivered by February 15, 2021

• Two-thirds by April 15, 2021

• A full draft of the complete manuscript by July 2021

As the book was eventually published in August 2022, you can imagine I was slightly late. But when I spoke with people at Manning, they told me most technical books are late. We all know that in tech, we’re not great at planning. So why would it be any different when we start writing books? 🙂

Jokes aside, at that stage, I didn’t fully realize how much work was ahead of me, so July 2021 seemed doable.

Starting to Write and Meeting My DE

At the very beginning, Manning asked me to think deeply about what they call the MQR: Minimum Qualified Reader. In a nutshell, what’s the minimum level of knowledge or experience someone needs to read your book?

That may sound like a basic question, but at that point, I hadn’t even considered it. Over the next few weeks, I refined my MQR to target someone who already knows the Go language. That meant about 15% of my content could go directly into the nearest trash can as it was just too basic.

Around the same time, I met the person who probably had the biggest impact on the book: my development editor (DE).

A DE helps refine the structure, content, and flow of a manuscript to improve things like clarity, coherence, and how well ideas are conveyed. Note that a DE doesn’t need to be a technical person. Mine had some experience in computer science but absolutely none in Go, and that was perfectly fine. We don’t expect technical reviews from a DE but instead, a valuable contribution to the quality of the writing.

NOTE: This was the person who taught me the key lessons I shared in 10 Rules I Learned About Technical Writing.

I learned a ton from my DE. Like, really, a ton. Before that, I had been writing on various blogs for about a decade, but writing online is all about being direct because most people don’t have time. With a book, it’s different. People made a deliberate decision to buy your book. Now, it’s your job to bring them somewhere valuable. And if that takes time (meaning more words), so be it.

For example, here’s how I introduced one mistake in The Top 10 Most Common Mistakes I’ve Seen in Go Projects post:

And here’s how I approached the same mistake in my book:

This isn’t about being verbose just to add pages to increase the book’s price. It’s about making sure the flow works well, that readers know where you’re going, and that they can follow you all the way. There’s a huge gap between writing a blog post and writing a book.

NOTE: In my newsletter, I try not to keep that gap too big. I feel like someone who deliberately shared their email is also making a clear statement: “I’m interested in your content”. I don’t take as much time as I do in the book, but I definitely take more than I did in my older blog posts.

This is just one example, but my DE helped me massively. I absolutely loved every single bit of his feedback. To be honest, at the beginning of our collaboration, he had a lot of comments. Some things I picked up quickly, but others were much more difficult for me. Yet, over the next months, I will significantly improve my writing.

Mindset

I wanted to talk a little bit about my mindset when I started writing the content of my book, chapter after chapter, mistake after mistake.

At this stage, my mindset was simple: I wanted to write the best Go book. Period.

Let me clarify, though, just to make sure I don’t come across as someone full of ego, as there’s an important nuance here. I wasn’t thinking, “My book is going to be the best.” Instead, I was thinking, “I will give everything I have to bring it to a level where it could be considered the best.”

I already knew at that point that it would probably be my first and last book. So, if I was going to write one, I might as well give everything I had to make sure that what’s going to sit on my shelf for the rest of my life is something I will be proud of.

Also, having this mindset was a commitment to future readers: you bought my book, I don’t know if you’ll love it, but I promise it’s the best version I could have made.

Subscribe now

1P

1P stands for first part. Basically, the process that starts once one-third of the book is written and accepted by the DE (which happened for me after a lot of back and forth to be honest).

For each third of the book (1P, 2P, and then 3P), the process is similar: the manuscript is sent to external reviewers who can leave comments directly on your text but also fill out a detailed document with questions like:

• Is the writing interesting? Does it hold your attention?

• Are the examples good and applicable in the real world? Are there enough of them?

• What do you think of the overall concept of the book and the approach toward the

  intended audience?

This document is very thorough. These reviews are invaluable for an author. While you can be confident that the writing itself is fairly solid thanks to the work you were doing with your DE, from a technical standpoint, this is really the first time your content is being confronted by other technical people.

We got the results for 1P in April 2021. In total, I received 13 reviews, with an average star rating of 4.10 out of 5. Not a fantastic score, but at that point, it was OK. I wasn’t too disappointed.

Of course, some of the feedback you receive as an author can hurt:

But if it hurts, it probably means there’s some truth behind it. You have to accept it and improve your book.

During that period, Manning offered to connect me with another author, Bill Kennedy, who also wrote a book with them called Go in Action. Beyond the fact that I have immense respect for him (he’s one of the people who contributes the most to the Go ecosystem), Bill taught me something crucial:

That was golden advice. Thanks to Bill, I gave my best to address (almost) every single comment, from changing a single word to fully rewriting how a mistake was explained.

A Technical DE?

It’s time to talk about my first hiccup with Manning (there will be two).

I already explained how crucial my development editor (DE) was in the process. However, I was also supposed to be accompanied by another person: a technical development editor (TDE).

While external reviewers only come in at each third of the book, the TDE is supposed to work more closely with the author throughout the entire process, helping shape the content, the overall structure, how chapters are divided, and so on.

This isn’t a personal criticism, but my TDE simply wasn’t an MQR. This means he didn’t have the basic Go knowledge expected from someone reading the book. Of course, I wasn’t expecting the world’s top Go expert as a TDE, but I did expect someone who at least matched the Minimum Qualified Reader profile, a concept introduced by Manning themselves. That felt like the bare minimum.

I raised this issue with Manning after 1P, but unfortunately, they didn’t really listen and kept the same TDE on the project. I was a bit annoyed, to be honest, but I had to move on.

MEAP

Until 1P, the book is in a kind of trial phase, meaning that either Manning or the author can still decide to stop the collaboration. Apparently, a certain percentage of books fail at 1P when Manning realizes that external reviewers aren’t convinced by how the initial idea is being executed.

After 1P, Manning launches their Manning Early Access Program (MEAP), which allows people to buy the book and access it while it’s still being written. For the author, it becomes an additional source of feedback, as readers can leave comments on an online platform.

When we say people can start buying your book, it also means a shift for Manning: it’s time to sell it.

That brings a few new responsibilities, like keeping the content regularly updated for those who already paid, writing a welcome letter for MEAP readers, and starting to work with the marketing team on how to promote the book and raise awareness about it.

On that last point, Manning asked me several times during this period to promote the book at public events (meetups, conferences, etc.), but I always declined. Writing was already taking up so much time and energy that I didn’t feel like adding one more thing to my plate by preparing talks.

The only “promotion” I did during that time was joining a podcast since it required less preparation. I was invited to Go Time, which was a weekly podcast about Go and the most popular one in the community (unfortunately, it stopped).

The episode I appeared in, titled sarcastically How to make mistakes in Go, was really well received. That was another interesting signal that talking about mistakes was a compelling angle.

Choosing a Book Cover

During that period, it was time to choose a book cover. Manning has a (very) special way of illustrating their books, all based on drawings from Jacques Grasset de Saint-Sauveur, an 18th-century illustrator.

At first, I received a few illustration options, including this one:

In a very delicate and constructive manner, I decided to share my opinion:

The truth is, while I usually enjoy Manning books, I find all their covers pretty bad. Compared to other publishers like No Starch Press, I definitely prefer what others are doing.

I remember having a hard time explaining to my family that my programming book would have this on the cover:

But hey, it is what it is. I guess it contributes to a certain visual identity for Manning. And in the end, if we take a step back, the cover really isn’t that important… right?

2P

We’re in August 2021, four months after 1P, and it’s now time for 2P. In retrospect, having only four months to complete the second third of the book was a brutal pace. Looking at some old emails with my DE, it’s clear that this period was particularly exhausting for me:

Anyway, it’s 2P, and this time I received 13 reviews with an average rating of 4.15. So I went from 4.10 to 4.15, and honestly, at that point, I was starting to feel a bit disappointed.

I’m a regular user of Goodreads. On that platform, books are also rated out of 5 stars; in my mind, a “great” book starts at 4.5 and up. Why 4.5? No idea. But that was definitely my goal.

4.15 isn’t bad, but it’s still far from 4.5. So yes, I was disappointed but not dejected. Once again, I went through all the reviews, and I just kept improving the book over and over.

To give you a sense of what I mean by improving the book “over and over“, keep in mind that between feedback from my DE, external reviewers, and others, there are parts of the book that I rewrote more than ten times. I don’t know if that’s common, to be honest. Maybe it’s because I was terrible at the beginning. Maybe it’s because I’m literally obsessed with details. Or maybe it’s both.

3P

From 2P to 3P is almost a blackout for me. This time, the period lasted five months, during which I wrote the last third of the book and completely rewrote the first few chapters. Indeed, once I reached the end of the book, I reread the first part and thought: “This is awful; I can’t publish that.”

That’s more proof that going through the long, demanding process of writing a book really did improve my writing skills. Some parts that felt fine in the beginning ended up being terrible once I had more experience.

From those five months, I only clearly remember one week of "holiday" that I spent working on my book. And by week, I don’t mean a peaceful 40-hour work week. I mean waking up at 3 p.m., working 14 to 15 hours straight, and going to bed around 8 a.m.

Funny enough, I didn’t hate that week. In my mind, it was my author week. If I had crossed a stranger on the street and they had asked what I did for a living, I would’ve proudly said: “I’m an author!”

Unfortunately, I didn’t speak to anyone that week. Except my janitor.

But during that week, I made a lot of progress. I managed to write the first draft of the last chapter. I’m sharing this to give you an idea of the pace. The book had 12 chapters, and the one that went the fastest still took me about 100 hours to write. You can imagine how long the rest took. And that’s not even counting the endless rewrites after all the feedback from my DE and the reviewers.

During that period, I also worked on my inside cover. I’m a big fan of Designing Data-Intensive Applications by . His book is full of beautiful visual maps like this one:

I wanted a similar vibe, so I created this:

The map is full of tiny easter eggs. For example, Kennedy Sea, Cox River, Cheney Ocean, Mount Dogan, or even Deleplace Tower. It was my way of giving a nod to the people in the Go community who helped me the most through their content.

So, it’s January 2022, and we finally receive the results from 3P.

In total, I got 15 reviews and an average rating of… 4.6/5. Nice! 😊

And speaking of good news, around the same time, Manning finally decided to switch my TDE to someone else, Tim van Deurzen. If you want a simple anecdote to understand Tim’s importance was for this book: during 3P, I received feedback from 15 reviewers. Yet I think Tim’s single review was possibly as valuable as all the others combined. The guy is an absolute rockstar; my book wouldn’t have been the same without him. Thanks again, Tim. 🙇‍♂️

One more month of work to take all the reviews into account, and…

🥂 Finished!

We’re at the end of February 2022, and the book officially moves from the development stage to production. At this stage, only a few steps remain, and they are mostly handled by the publisher:

• Copyediting to refine grammar, style, and consistency

• Proofreading to catch spelling, punctuation, and formatting errors

• Typesetting to arrange the text, code, and images for publication

• Indexing to compile a list of key terms and topics with page references

One thing to note: from an author’s standpoint, the book is more or less complete at this stage. You can still add minor things, but the publisher wants to lock in a first version. That’s because adding even a single new paragraph means going through the process again for that section. That’s why publishers insist on fixing the version.

Reaching that point is a big milestone. To express what I felt at the time, there’s a great quote by Gene Fowler:

Real question: how can you say a book is finished? For example, I could have improved a figure here, tweaked an example there, rephrased a sentence, or refined a conclusion. But that loop could have lasted forever. At some point, you just have to consider this version final, move to the next stage, and, in a way, abandon your book.

It’s a tough feeling, but that’s how it goes.

That being said, finishing a book calls for a celebration. I remember having a drink one evening with my girlfriend, and we toasted to “the end of the book.” 🥂

Once again, I was way too naive.

“I’ll Stop Everything“

It’s now time to talk about my second hiccup with Manning, but this time, it was way more serious.

We started the copyediting process, which is meant to refine grammar, style, and consistency. I don’t know about you, but I imagined the author’s involvement at this stage would be pretty lightweight, right? Absolutely not. At least, not for my book.

First, the review process was an exercise in frustration and inefficiency.

During the development phase, I wrote everything in AsciiDoc, generated content, and got feedback either as PDF comments from the DE or through the Manning website from reviewers.

But copyediting was different. The copyeditor was directly editing my content and leaving questions in the source itself.

To clarify, my content was stored in a Git repository. Instead of going through a classic pull request (PR) workflow, the copyeditor was directly modifying the source files and adding comments on top of that.

For example, here is my original sentence:

Throughout this section we also used an example with errors because ...

And here’s what it looked like after her changes:

// AQ: please clarify leading to this error. Which error?
In this section, we used an example with errors because ...

So she was:

• Modifying the content directly

• Adding comments in the source code itself (🤯)

I tried to explain how review workflows work in a PR-based setup, and gave concrete suggestions for how we could improve the process. But they didn’t want to try it. That might sound like a small thing, but at that stage, all I wanted was a smooth and efficient collaboration process. The easier it was for me to track changes, the better.

But if that were the only problem, it would have been fine. Unfortunately, it was way more than that.

To put it simply, my experience with the copyeditor was catastrophic. She completely wrecked the content and introduced countless typos and mistakes.

For example, many of the issues came from her confusing the programming language Go with the verb to go. That led to many sentences that made absolutely no sense anymore.

Let me be clear: it’s totally fine if a copyeditor introduces a few mistakes. It’s supposed to be a collaborative process: they adapt the content, we go back and forth, and we improve it together.

But in this case, the number of mistakes was absurd. In just one chapter, she introduced 23 errors. I don’t mean things that could be improved; I mean factual errors. Now multiply that by 12 chapters.

And it wasn’t just about errors. When I asked questions like, “Why did you remove this sentence? I think it’s an important transition, and we should keep it”, she would sometimes just delete my comment. Such a great collaboration, right?

Eventually, when I raised more and more concerns, what was her response?

She basically said chapters 1 to 5 were ready to move to the next phase without even letting me fix the mistakes she introduced.

Let me try to put you in my shoes so you understand how I felt.

You’ve spent 15 months writing your book. You’ve done countless iterations to carefully improve every single one of the 100 mistakes. You’ve spent more hours than you can count. You’ve carefully processed hundreds, if not thousands, of pieces of feedback. You even took dedicated holidays just to make progress on it. And then, all of a sudden, someone jumps into your book, completely butchers it, and says, “These chapters are ready!”

How would you feel?

Well, that’s exactly how I felt. And to be honest, it was too much for me. I wrote an escalation email (which I won’t share here as it was way too salty) explaining that until this was resolved (meaning she had to leave), I would stop working on my own book.

To be fair to Manning, the situation was handled fairly quickly. Especially by one person: my acquisition editor (the scout). I really think that he saved the book. Because at that point, I swear that I was ready to give up everything.

In March 2022, the copyeditor stopped working on my book (she was external to Manning), and I was assigned someone new. That change was a huge relief.

Unfortunately, it meant going through everything again. I had to fix myself every single error she had introduced in the first five chapters, which delayed the book and cost me way more time and energy than I had anticipated.

Finally, at the end of July 2022, after six months of work after I thought the book was "finished", we reached the end. And this time, for real.

Did I try to celebrate again with my girlfriend? Yes. What did she reply? “I can’t trust you anymore with your book.”

Happiness?

A few months later, I received a box in the mail. I opened it, and inside were copies of my own book, sent by Manning. As you can imagine, I must have felt a mix of pride and extreme happiness, right? Nope.

I just couldn’t feel anything. I remember holding my own book in my hands and thinking, “What’s wrong with me? Why can’t I just be happy?”

This feeling isn’t that uncommon and is often referred to as post-publication depression.

It’s incredibly hard to put words to what I was feeling. It was around August 2022 and I had started working on the content back in July 2019. That’s almost three years of work. It had been such an intense period, and suddenly it was over.

It wasn’t really sadness. Just… emptiness, I would say.

Over the following months, I slowly started to recover and eventually became very positive about the whole experience. But that moment really changed the way I look at other people’s work.

When we evaluate something, a coding project, a book, or an illustration, we often forget how much time, energy, and emotion someone may have poured into it. We have no idea what that work cost them.

Promotion?

So, the book is released, and everyone can buy it. Time for promotion!

I started with one Reddit post of 175 words, followed by a tweet of 49 words:

In total, writing these 224 words took me around 10 minutes. And after that? Nothing for more than a year.

There were two main reasons.

First, I was mentally exhausted. Especially after the painful six-month process where I thought my book was finished, but it wasn’t; I just had no energy left. I kept declining Manning’s requests to promote the book at conferences, meetups, YouTube videos, Twitch streams, and so on.

Second, I developed this belief: if my book was good, people would talk about it and share it. I don’t know if I was being delusional, lucky, or a mix of both, but it turns out I was right. The number of people who kept commenting on the book across Reddit, X, YouTube, and other platforms was absolutely sensational for me.

One important thing to clarify. This wasn’t about being overconfident or full of ego, like, “Yeah, my content is so good, of course people will talk about it!”

It was more like, “If my book is worth sharing, people will share it. If not, then should I really bother promoting something people don’t even enjoy?”

Of course, it would’ve broken my heart if people said the content was terrible. But still, that was really my mindset during that year, and honestly, it hasn’t changed much since then.

A year later, in September 2023, with the help of people from the Go community, I released 100go.co, which contains a summary of all the mistakes in the book:

That website was kind of a way to close the loop on my initial wish to create open-source content. People who can’t or just don’t want to buy the book can still visit 100go.co and access a significant part of the content for free. The traffic ended up being quite strong for such a specialized website: 150k views in 2024.

I discussed 100go.co with Manning, and they said it was a “brilliant idea”. They even offered me a paid role to help other authors promote their content.

In all honesty, I think they overestimate my sales skills. I haven’t done a lot in that area. For example, last year, I gave a talk at a public conference, and I didn’t even mention that I had written a book. Not because I hate promotion. Well, I do, but that wasn’t the main reason. The real reason was that mentioning my book wouldn’t have improved this talk in any way. So I just didn’t say anything.

What about Manning’s offer to help other authors? I didn’t take it.

If it were up to me, people would still have the option to buy my book physically, but the whole content would be available online for free, with no login required.

I’ve considered talking to Manning about that. We will see if they still believe I have “brilliant” ideas. 😅

Translations and Total Sales

At the end of 2022, Manning informed me they had secured licensing deals for four translations. For each of them, I received a fixed payment along with royalties. For example, I earned $4,000 and 6% royalties for the Japanese translation.

As of the end of September 2025, the English version had sold 13,258 copies.

I don’t have the sales figures for the translations, but someone at Manning told me that usually, the combined sales of all translated versions may match the English copies sold.

NOTE: My book also started a new Manning series called 100 … Mistakes and How to Avoid Them, with editions in Java, C++, and SQL Server, for instance.

To this day, I’ve earned around $54,000 from the book (before taxes). If I consider the time spent, using a conservative lower bound of 2,000 hours, that comes out to about $27 per hour.

There are two ways to look at that hourly rate.

One could say it’s pretty low compared to what a software engineer could earn. I could have invested 2,000 hours into some paid technical work and probably made a lot more.

The other way to approach it is not to care too much about it. Sure, the money I earned isn’t negligible (it paid for quite a few holidays, to be honest), but my main message is this: if you’re a new author, don’t think about writing your book to become rich.

I’m sure there are well-known authors like Robert Martin who can make significant income from pretty much any book they release. But for the rest of us, the “normal” authors, we can’t and shouldn’t aim to get rich, especially from a single book.

For me, the money I earned from this book was never the goal. I’m happy with it, of course, but that’s not where my main motivation was.

It was somewhere else.

Conclusion

So, did I reach my secret goal of getting a rating over 4.5? Yes, I did!

Did I write the best Go book? Probably not. There are many great books out there and to me, a book like Ultimate Go Notebook is the best one, in my opinion.

But in the end, do I really care if my book is the best or not? Not really.

The goal of writing the “best Go book” was just a personal motivation, something to push me to do the best I could at that specific time in my life. The book is not perfect, but it’s the best version I could have written then.

And for that, I will always be proud of it.

Teiva

P.S. I don’t know about Go rankings but at least my book was listed among the Best 8 JavaScript Books for Developers in 2024. Being a Go book that’s an achievement, isn’t it?

Thanks to:

• The Go community. If I fell in love with this language, it’s also because most people there are very supportive.

• All the readers of the book.

• All the reviewers and Tim, who helped me shape something far better than I could have done on my own.

• My DE and my acquisition editor who were the two pillars of this book.

• Manning. I don’t know how you will perceive my story, but in the end, I’m really grateful to Manning, and I’m glad they were the only publisher I had ever contacted.

• The readers of The Coder Cafe. After a long period where I couldn’t write anything at all, this newsletter reminded me how much I love writing.

📚 Resources

More From the Lattes & Stories Section

• What I Learned During My Paternity Leave

• Why I Switched to Vim Keybindings

Explore Further

• Hacker News discussion

• Yay! I Finished My Book! So Why Do I Feel So Depressed?

❤️ If you made it this far and enjoyed the post, please consider giving it a like.

💬 Manning recently contacted me about doing a second edition. I’m thinking about it and would love to hear your thoughts.

Leave a comment