Les coulisses du livre « 100 erreurs en Go et leurs solutions »

• Un récit centré sur le cheminement personnel qui a conduit l’auteur à se passionner pour le langage Go et à écrire ce livre
• Le retour d’expérience d’un ouvrage achevé sur trois ans après le succès d’un billet de blog et la signature d’un contrat avec Manning
• Un texte qui décrit avec franchise les nombreux tâtonnements et montagnes russes émotionnelles, en particulier les tensions du processus éditorial

Première rencontre avec le langage Go, puis tournant décisif

• En 2018, après un travail de PoC en Scala/Akka en Suisse, l’auteur est séduit par l’efficacité et la simplicité du langage Go
• En utilisant Go dans une nouvelle entreprise, il accumule de l’expérience terrain et commence à écrire des billets de blog en voyant ses collègues répéter les mêmes erreurs
• Un billet publié sur Medium reçoit un écho bien plus important que prévu, ce qui lui donne confiance dans l’écriture

Le début de la publication du livre : de l’idée au contrat

• Dans la continuité du billet de blog, il élabore un projet visant à rassembler 100 cas d’erreurs en Go pour l’étendre en livre
• Il n’envoie une proposition d’édition qu’à Manning et reçoit rapidement une réponse positive par un simple email
• Après les retours positifs de 7 relecteurs externes, le contrat officiel est signé en décembre 2020

Le processus d’écriture et la collaboration avec les éditeurs

• Après avoir défini le « lecteur minimum qualifié » (MQR), il supprime sans hésiter les bases superflues
• Il explique avoir amélioré sa technique d’écriture en collaborant avec un development editor (DE) non technique
• Certaines chapitres ont été réécrits plus de 10 fois au fil des cycles répétés de relecture et de révision

Relectures externes et prise en compte des retours

• Le livre fait l’objet de revues techniques externes en trois étapes (1P, 2P, 3P), avec des notes en progression constante
• 1P : 13 relecteurs, moyenne de 4,10 → 2P : 4,15 → 3P : 4,6
• Le principe d’acceptation des retours vient d’un conseil de Bill Kennedy : « ne pas ignorer un seul feedback »

Grande crise pendant le processus éditorial

• Le technical development editor (TDE) initialement désigné manquait même des connaissances de base sur Go, ce qui provoque du mécontentement
• Le système de correction complexe et l’inefficacité du mode de collaboration posent problème, et l’éditeur va même jusqu’à introduire massivement des erreurs
• Profondément frustré, l’auteur annonce l’arrêt du travail, puis Manning résout rapidement le problème en affectant un nouvel éditeur

Le chemin jusqu’à l’achèvement et le vide après la parution

• Une fois tout terminé, ce n’est pas tant le sentiment de « c’est fini » qu’un grand vide qui l’envahit (déprime post-publication)
• Toute l’énergie et les émotions investies pendant près de trois ans disparaissent en un instant
• Avec le temps, il se remet progressivement et retrouve sa fierté vis-à-vis du contenu qu’il a créé

Le succès du livre et la réaction de la communauté

• Juste après la sortie, sans longue promotion, des partages spontanés apparaissent sur Reddit, Twitter et d’autres plateformes
• Un an plus tard, il propose gratuitement du contenu de synthèse via le site open source 100go.co
• Manning réagit également positivement et lui propose même à l’avenir un rôle de soutien aux auteurs

Droits d’auteur, revenus, et une signification qui va au-delà

• Fin 2024, l’édition anglaise s’est vendue à 11 452 exemplaires, pour un revenu total d’environ 47 000 $
• Le revenu horaire reste faible, mais l’auteur accorde plus d’importance à la contribution à la communauté et à l’accomplissement personnel qu’à l’argent
• Le livre a influencé des séries suivantes sur Java, C++, SQL Server et d’autres sujets

Conclusion et résolution personnelle

• L’objectif est dépassé avec une note Goodreads de 4,66
• Ce n’est peut-être pas le meilleur livre sur Go, mais l’auteur est convaincu que c’est le meilleur qu’il pouvait créer à ce moment-là
• Une proposition pour une 2e édition lui a aussi été faite, et il attend les retours des lecteurs

[zihado]

https://product.kyobobook.co.kr/detail/S000211704725
C’est ce livre.

[GN⁺]

Avis sur Hacker News

• Le workflow de relecture a été décrit dans une configuration basée sur les PR et des suggestions d’amélioration ont été faites, mais l’autre partie ne voulait pas essayer. L’objectif était d’avoir une collaboration plus fluide et plus efficace
• Il était surprenant que le correcteur-réviseur soit plus à l’aise avec git qu’avec un outil de relecture web. En particulier, en relisant un livre sur Go, il ne semblait pas très bien connaître Go
• Il semble étrange que Manning ait un correcteur-réviseur
• Partage d’une expérience négative avec Manning. La personne écrit un livre et l’autoédite, et avait demandé s’il était possible de proposer une deuxième édition à Manning. Ils ont répondu en refusant la proposition
• Seul Google Docs était mentionné comme format de document, mais d’après le billet de blog, il semble qu’AsciiDoc soit également accepté
• Mention d’un problème lié à sync.Pool, avec partage d’un lien connexe
• En regardant l’utilisation de sync.Pool dans la bibliothèque standard de Go, on trouve des pools à paliers de tailles variées, et les éléments de grande taille sont souvent écartés
• Partage d’une expérience d’écriture d’un livre chez Manning avec DocBook. Après la correction éditoriale, tout le contenu est revenu sur une seule ligne, ce qui a été décevant. La personne est ensuite passée à l’autoédition
• Le premier contact avec O'Reilly avait commencé par e-mail, et leurs outils sont mentionnés comme excellents. Ils peuvent générer la version complète d’un format pris en charge à partir d’un commit git
• Il est mentionné que le format du livre convient bien à un club de lecture. Les erreurs ont fait de bons sujets de discussion, et les personnes expérimentées ont partagé comment elles les avaient évitées
• Beaucoup des "erreurs" du livre servent à présenter certains aspects de Go, par exemple "ne pas utiliser le fuzzing" et "ne pas utiliser errgroup"
• Il est mentionné que la relecture de Tim était très précieuse, mais il est regretté qu’il n’y ait pas d’explication concrète sur cette relecture
• Un autre auteur de Manning fait l’éloge du livre en disant qu’il contient beaucoup d’informations pratiques. Il prévoit de s’y référer à nouveau en lançant un nouveau projet Go
• Une question est posée à propos d’un exemple lié aux goroutines. On se demande si, sans utiliser de goroutine et en créant une fermeture de fonction, on référencerait la même variable i
• Respect exprimé pour le fait que l’auteur ait su tirer des leçons des retours reçus et apprendre à mieux communiquer. Il est aussi mentionné qu’il a su adopter une attitude ferme face à un correcteur-réviseur problématique
• Partage d’une expérience de refactoring d’une base de code legacy en C++ en Suisse. C’était un bon environnement pour essayer une nouvelle stack puis, si cela s’avérait difficile, en essayer une autre
• Mention d’un ensemble de pages sur Sensei's Library consacré aux erreurs commises avec Go