📅 Last updated: October 7, 2025
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.
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:
If you get one comment, you must address it, even if it doesn’t seem important to you. If one person raised it, imagine when thousands of people read your book.
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 Martin Kleppmann. 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:
A book is never finished; it's abandoned.
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
Explore Further
❤️ 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.
Congratulations on releasing a gem
Fantastic read! It made me want to buy your book even more - a coworker introduced me to the work and the related website and I'm loving it!