Quick Take
- Narration: Christopher Kendrick reads with confidence and appropriate technical authority – handling the structured, mistake-by-mistake format cleanly without making the catalog feel repetitive.
- Themes: Go language idiomatic patterns, concurrency pitfalls, production-readiness and testing quality
- Mood: Precise and illuminating, with the satisfying texture of learning from someone who has made the mistakes themselves
- Verdict: The clearest and most comprehensive intermediate-to-advanced Go text available in audio, and one of the best format matches between a programming book and an audiobook you will find.
I have a specific memory attached to this one: a long train journey through the Alps, the kind where you give up on working and just listen. I was already using Go professionally and thought I knew it well enough. Within the first two hours of 100 Go Mistakes and How to Avoid Them, I had encountered three patterns I was almost certainly getting wrong. That is not a comfortable feeling, but it is exactly what a good technical book should produce – not the anxiety of discovering ignorance, but the relief of getting to name and fix it.
Teiva Harsanyi works as a software engineer with deep Go experience, and this book is built on a specific pedagogical bet: that the best way to understand a language deeply is to study where practitioners consistently go wrong, and why. The result is a catalog of 100 documented mistakes organized by category – types and data structures, control structures, strings, functions, error handling, concurrency, the standard library, testing, and optimization. Each mistake is explained in terms of what the incorrect pattern looks like, why it is incorrect, and what the idiomatic alternative is. The format is methodical without being dry, because Harsanyi consistently grounds each mistake in real code that real developers write.
What Separates Good Go from Idiomatic Go
One of the book’s recurring insights is the distinction between code that compiles and runs correctly and code that is idiomatic Go – code that leverages the language’s specific design for clarity, performance, and maintainability. Many of the 100 mistakes are patterns that developers bring from other languages and that work in Go but miss the point of how Go is designed. The slice handling chapters are a good example: the behaviors of append, cap, and len in Go have subtle implications for memory allocation and performance that are not intuitive coming from Python or JavaScript, and getting them wrong produces code that passes tests but allocates memory badly at scale.
The concurrency sections are the ones I returned to most. Go’s goroutine and channel model is elegant in the small examples you learn from, and frequently dangerous in production code where goroutine leaks, race conditions on shared state, and incorrect channel directionality accumulate invisibly until they cause failures. Harsanyi’s treatment of these mistakes is the most thorough I have encountered in audio format, partly because he explains not just what goes wrong but what mental model the developer was using when they wrote the code – which means the correction is more memorable than a pure syntax fix.
Christopher Kendrick and the Catalog Format
The 100-mistake catalog format creates an unusual challenge for audio production: there are exactly 100 units of content, each with a similar structure – here is the mistake, here is why it is a mistake, here is the better approach. In a bad audio production, this would feel like reading a checklist for twelve hours. Christopher Kendrick avoids that by varying his emphasis and pacing naturally within each entry, letting the most important passages breathe and moving through the contextual setup more efficiently. He reads as if he understands the material, which means he knows which sentences carry the conceptual weight and which are scaffolding.
The accompanying PDF (included with the Audible purchase) contains code examples that are naturally impossible to display in audio. For a book of this type, the PDF is genuinely load-bearing rather than supplementary – there will be passages where Kendrick describes a code pattern verbally and you are working hard to construct a mental image that a single code block would make immediately clear. Having the PDF open on a second screen while listening significantly improves the experience.
The Reviewer Consensus and What It Confirms
The review signal for this book is unusually strong. One reviewer came from an assembly and C background and calls the explanations “clear” and “detailed using actual lines of code that compile.” Another calls it the best Go book they have read in 2024. The reviewer who describes it alongside Go in Practice as the two best Golang books available is making a specific and testable claim, and the consistency across reviews suggests the book delivers on its promise for the audience it targets.
That audience, as the synopsis notes, is intermediate and advanced developers building complex software in Go. If you are learning Go for the first time, this is not your entry point – the books Harsanyi is implicitly writing against are the ones that taught you the basics. This is what comes after you know the basics and have started writing real code that could be better.
The Go Developer This Book Was Written For
Near-essential listening for any developer who uses Go professionally and has been doing so for at least a year. The pattern-recognition value of the book compounds with experience – the more Go code you have written, the more often you will recognize your own past mistakes in Harsanyi’s catalog. Less suited for Go beginners; the book assumes you can follow discussions of goroutines, interfaces, and testing patterns without foundational explanation. And if you are considering Go for a future project but have not started yet, this book will not orient you to the language – for that, look to The Go Programming Language or Go in Action first, then return here when you have written enough code for the mistakes to be recognizable.
Frequently Asked Questions
Do I need the PDF companion to get full value from the audiobook, or can I follow the code discussions by ear?
The PDF is included with your Audible purchase and is worth using alongside the audio. Harsanyi describes code patterns verbally throughout, and while the explanations are clear enough to follow without visual aids, having the code examples visible significantly reduces the cognitive load of constructing mental models. For a book covering 100 distinct technical patterns, the PDF transforms the experience from manageable to genuinely efficient.
Is this book appropriate for developers learning Go for the first time, or does it require prior Go experience?
The book requires intermediate Go experience. It assumes you are already comfortable with goroutines, interfaces, slices, and basic error handling, and it does not re-explain these from scratch. Reviewers consistently describe it as the book to read after you have been writing Go professionally for a year or more. Complete beginners should start with The Go Programming Language or Go in Action.
Which of the 100 mistakes do reviewers and practitioners find most valuable?
The concurrency mistakes and the slice/memory management sections are most commonly cited by reviewers as illuminating patterns they were getting wrong. The concurrency chapters cover goroutine leaks, race conditions, and channel misuse in ways that reflect real production failures. The slice chapters address memory allocation subtleties that are easy to miss and meaningful at scale.
How does 100 Go Mistakes compare to The Go Programming Language and Go in Practice for intermediate developers?
The Go Programming Language is the authoritative reference but not structured around practical pitfalls. Go in Practice covers a wider range of application patterns. 100 Go Mistakes occupies a specific niche: it is organized around mistakes, which means it directly addresses the gap between code that works and code that is genuinely idiomatic and production-ready. For an intermediate Go developer, it is complementary to rather than competitive with the others.
