Die Hintergrundgeschichte zum Buch „100 Go Mistakes and How to Avoid Them“

• Eine Erzählung, die sich auf den persönlichen Weg konzentriert, wie der Autor sich in die Sprache Go verliebte und schließlich das Buch schrieb
• Erfahrungsbericht darüber, wie aus dem Erfolg eines Blogposts ein Vertrag mit Manning entstand und das Buch über drei Jahre hinweg fertiggestellt wurde
• Ein lebendig geschriebener Text über zahlreiche Versuche und Irrtümer, emotionale Höhen und Tiefen und insbesondere Konflikte im Lektoratsprozess

Die erste Begegnung mit Go und der Wendepunkt

• 2018 arbeitete der Autor in der Schweiz nach einem PoC mit Scala/Akka und war von der Effizienz und Einfachheit von Go begeistert
• In einem neuen Unternehmen sammelte er praktische Erfahrung mit Go und begann Blogbeiträge zu schreiben, nachdem er gesehen hatte, dass Kollegen dieselben Fehler wiederholten
• Ein auf Medium veröffentlichter Blogbeitrag erhielt unerwartet viel Resonanz und gab ihm Selbstvertrauen beim Schreiben

Der Beginn der Buchveröffentlichung: von der Idee bis zum Vertrag

• Als Erweiterung der Blogbeiträge entstand der Plan, 100 Go-Fehlerfälle zu sammeln und zu einem Buch auszubauen
• Der Verlagsvorschlag wurde nur an Manning geschickt, und auf eine einfache E-Mail kam schnell eine positive Antwort
• Nach positivem Feedback von sieben externen Reviewern wurde im Dezember 2020 der offizielle Vertrag unterzeichnet

Schreibprozess und Zusammenarbeit mit den Lektor:innen

• Nach der Festlegung des „Minimum Qualified Reader (MQR)“ wurden unnötige Grundlageninhalte konsequent entfernt
• Durch die Zusammenarbeit mit einem nichttechnischen Development Editor (DE) verbesserte der Autor seine Schreibfähigkeiten
• Es gab Kapitel, die durch wiederholte Reviews und Überarbeitungen mehr als zehnmal neu geschrieben wurden

Externe Reviews und der Umgang mit Feedback

• Das Buch durchlief in drei Phasen (1P, 2P, 3P) externe technische Reviews, wobei sich die Bewertungen schrittweise verbesserten
• 1P: 13 Reviewer, Durchschnitt 4,10 Punkte → 2P: 4,15 Punkte → 3P: 4,6 Punkte
• Das Prinzip beim Umgang mit Feedback stammt aus Bill Kennedys Rat: „Nicht einmal ein einziges Feedback ignorieren.“

Die große Krise im Lektoratsprozess

• Der anfangs zugewiesene Technical Development Editor (TDE) verfügte nicht einmal über grundlegendes Go-Wissen, was für Unmut sorgte
• Ein komplexes Korrektursystem und ineffiziente Zusammenarbeit verursachten Probleme, und der Editor fügte sogar in großem Umfang Fehler ein
• Aus großer Frustration erklärte der Autor einen Arbeitsstopp, woraufhin Manning schnell einen neuen Editor zuwies und das Problem löste

Der Weg zur Fertigstellung und die Leere nach der Veröffentlichung

• Nachdem alles abgeschlossen war, stellte sich statt des Gefühls „Es ist vorbei“ eher Leere ein (Post-Publication-Depression)
• Die Energie und Emotionen, die fast drei Jahre lang hineingeflossen waren, verschwanden in einem Augenblick
• Danach erholte sich der Autor allmählich und gewann den Stolz auf die von ihm geschaffenen Inhalte zurück

Der Erfolg des Buchs und die Reaktion der Community

• Direkt nach der Veröffentlichung wurde das Buch ohne lange Werbephase auf Reddit, Twitter und anderswo spontan geteilt
• Ein Jahr später stellte der Autor über die Open-Source-Seite 100go.co kostenlose zusammenfassende Inhalte bereit
• Auch bei Manning fiel die Resonanz positiv aus, und dem Autor wurde später sogar eine unterstützende Rolle für andere Autor:innen angeboten

Tantiemen, Einnahmen und ihre darüber hinausgehende Bedeutung

• Stand Ende 2024 wurden von der englischen Ausgabe 11.452 Exemplare verkauft, mit Gesamteinnahmen von rund 47.000 US-Dollar
• Der Stundenlohn ist niedrig, doch wichtiger als Geld sind für den Autor der Beitrag zur Community und die persönliche Erfüllung
• Das Buch beeinflusste auch nachfolgende Reihen zu Java, C++ und SQL Server

Abschluss und persönlicher Vorsatz

• Mit einer Goodreads-Bewertung von 4,66 wurde das Ziel übertroffen
• Es ist vielleicht nicht das beste Go-Buch überhaupt, aber der Autor ist überzeugt, dass es damals das beste Buch war, das er machen konnte
• Ein Vorschlag für eine zweite Auflage liegt ebenfalls vor, und nun wartet er auf Feedback der Leser:innen

[zihado]

https://product.kyobobook.co.kr/detail/S000211704725
Das ist dieses Buch.

[GN⁺]

Hacker-News-Kommentare

• Der Review-Workflow wurde in einer PR-basierten Konfiguration erläutert und Verbesserungsvorschläge wurden gemacht, aber die andere Seite wollte es nicht ausprobieren. Gewünscht waren ein reibungsloserer und effizienterer Kollaborationsprozess
• Es war überraschend, dass der Copy-Editor mit git vertrauter war als mit webbasierten Review-Tools. Besonders bei der Review eines Go-Buchs schien er sich mit Go nicht gut auszukennen
• Es fühlt sich seltsam an, dass Manning einen Copy-Editor hat
• Es wurde eine negative Erfahrung mit Manning geteilt. Jemand schreibt ein Buch und veröffentlicht es im Selbstverlag und fragte an, ob Manning Interesse an einer zweiten Auflage hätte. Sie antworteten, dass sie den Vorschlag ablehnen
• Als Dokumentformat wurde nur Google Docs erwähnt, aber laut dem Blogbeitrag scheint auch AsciiDoc akzeptiert zu werden
• Es wurde ein Problem im Zusammenhang mit sync.Pool erwähnt und ein relevanter Link geteilt
• Wenn man sich die Verwendung von sync.Pool in der Go-Standardbibliothek ansieht, gibt es gestufte Pools in verschiedenen Größen, und große Einträge werden oft verworfen
• Es wurde eine Erfahrung geteilt, ein Buch bei Manning mit DocBook geschrieben zu haben. Nach dem Copy-Editing kam alles wieder in einer einzigen Zeile zurück, was enttäuschend war. Danach wurde auf Selbstverlag umgestellt
• Der erste Kontakt mit O'Reilly begann per E-Mail, und ihre Tools wurden als hervorragend bezeichnet. Damit lässt sich aus einem git-Commit eine vollständige Version in unterstützten Formaten erzeugen
• Es wurde erwähnt, dass das Format des Buchs gut für einen Buchclub geeignet sei. Die Fehler waren gute Diskussionsthemen, und erfahrene Leute teilten, wie sie diese Fehler vermieden haben
• Viele der "Fehler" im Buch dienen dazu, bestimmte Aspekte von Go einzuführen, etwa "kein Fuzzing verwenden" und "errgroup nicht verwenden"
• Tims Review wurde als sehr wertvoll bezeichnet, aber es war enttäuschend, dass es keine konkretere Beschreibung der Review gab
• Ein anderer Manning-Autor lobte das Buch und sagte, es enthalte viele praktische Informationen. Beim Start eines neuen Go-Projekts wolle er erneut darauf zurückgreifen
• Es wurde eine Frage zu einem Beispiel mit goroutines gestellt. Wenn man ohne goroutine einen Funktions-Closure erstellt, würde dieser dann dieselbe Variable i referenzieren?
• Es wurde Respekt dafür ausgedrückt, wie der Autor Feedback annimmt und lernt zu kommunizieren. Erwähnt wurde auch, dass er gegenüber einem problematischen Copy-Editor entschlossen auftrat
• Es wurde eine Erfahrung mit dem Refactoring einer C++-Legacy-Codebasis in der Schweiz geteilt. Gut war ein Umfeld, in dem man einen neuen Stack ausprobieren und, wenn es schwierig wird, etwas anderes versuchen konnte
• Auf Sensei's Library wurde eine Sammlung von Seiten zu in Go gemachten Fehlern erwähnt