Os bastidores do livro "100 erros em Go e soluções"

• Um relato centrado no que levou o autor a se apaixonar pela linguagem Go e na jornada pessoal que o levou a escrever o livro
• A experiência de começar com o sucesso de um post de blog, assinar com a Manning e concluir o livro ao longo de 3 anos
• Um texto que descreve vividamente inúmeros erros e acertos e altos e baixos emocionais, especialmente os conflitos no processo editorial

O primeiro encontro com a linguagem Go e o ponto de virada

• Em 2018, após trabalhar em um PoC com Scala/Akka na Suíça, o autor ficou encantado com a eficiência e a simplicidade da linguagem Go
• Em uma nova empresa, acumulou experiência prática com Go e, ao ver colegas repetindo os mesmos erros, começou a escrever posts no blog
• O post publicado no Medium teve uma repercussão muito maior do que o esperado, dando-lhe confiança para escrever

O início da publicação do livro: da ideia ao contrato

• Como extensão do post no blog, foi elaborado um plano para reunir 100 casos de erros em Go e expandi-los em um livro
• A proposta editorial foi enviada apenas para a Manning, e uma resposta positiva chegou rapidamente por meio de um e-mail simples
• Após receber feedback positivo de 7 revisores externos, o contrato oficial foi assinado em dezembro de 2020

O processo de escrita e a colaboração com os editores

• Depois de definir o “leitor minimamente qualificado (MQR)”, conteúdos básicos desnecessários foram removidos sem hesitação
• Ao colaborar com um editor de desenvolvimento (DE) não técnico, o autor aprimorou suas habilidades de escrita
• Houve capítulos que foram reescritos mais de 10 vezes por causa do processo repetitivo de revisão e correção

Revisão externa e incorporação de feedback

• O livro passou por revisão técnica externa em 3 etapas (1P, 2P, 3P), com notas cada vez melhores
• 1P: 13 revisores, média de 4,10 pontos → 2P: 4,15 pontos → 3P: 4,6 pontos
• O princípio para aceitar feedback veio do conselho de Bill Kennedy: “não ignore nem um único feedback”

A grande crise durante o processo editorial

• O editor técnico (TDE) designado no início gerou insatisfação por não ter sequer conhecimento básico de Go
• O sistema complexo de revisão e a ineficiência da forma de colaboração, além de o editor inserir erros em massa, agravaram o problema
• Em meio a grande frustração, o autor declarou que interromperia o trabalho, e a Manning resolveu o problema rapidamente ao designar um novo editor

A jornada até a conclusão e o vazio após a publicação

• Depois que todo o processo terminou, em vez da sensação de “acabou”, veio um sentimento de vazio (depressão pós-publicação)
• A energia e as emoções investidas por quase 3 anos pareceram desaparecer de uma só vez
• Depois, aos poucos, o autor se recuperou e retomou o orgulho pelo conteúdo que criou

O sucesso do livro e a reação da comunidade

• Logo após o lançamento, sem uma longa campanha de divulgação, houve compartilhamento espontâneo no Reddit, Twitter e outros canais
• Um ano depois, o site open source 100go.co passou a oferecer conteúdo resumido gratuito
• A Manning também respondeu positivamente e chegou a propor um papel de apoio a autores no futuro

Royalties, receita e o significado além disso

• Até o fim de 2024, a edição em inglês vendeu 11.452 cópias, gerando cerca de US$ 47.000 em receita total
• O ganho por hora é baixo, mas o autor atribui mais valor à contribuição para a comunidade e à realização pessoal do que ao dinheiro
• O livro influenciou séries seguintes sobre Java, C++ e SQL Server

Encerramento e compromisso pessoal

• A nota no Goodreads chegou a 4,66, superando a meta inicial
• Talvez não seja o melhor livro sobre Go, mas o autor está convencido de que era o melhor livro que podia fazer naquele momento
• Ele também recebeu uma proposta para uma 2ª edição e está aguardando o feedback dos leitores

[zihado]

https://product.kyobobook.co.kr/detail/S000211704725
É este livro.

[GN⁺]

Comentários do Hacker News

• Foi explicado o fluxo de revisão em uma configuração baseada em PR e foram feitas sugestões de melhoria, mas a outra parte não quis tentar. Queria-se mais fluidez e eficiência no processo de colaboração
• Foi surpreendente que a copy editor estivesse mais acostumada a usar git do que uma ferramenta de revisão baseada na web. Especialmente ao revisar um livro de Go, ela parecia não conhecer muito bem Go
• Parece estranho que a Manning tenha uma copy editor
• Foi compartilhada uma experiência negativa com a Manning. A pessoa está escrevendo um livro e o publicando por conta própria, e perguntou sobre a possibilidade de submeter uma segunda edição à Manning. Eles responderam recusando a proposta
• Só foi mencionado o Google Docs como formato de documento, mas, segundo a postagem no blog, parece que AsciiDoc também é aceito
• Foi mencionado um problema relacionado a sync.Pool, com um link relevante compartilhado
• Ao observar o uso de sync.Pool na biblioteca padrão do Go, há pools em camadas de vários tamanhos, e itens maiores muitas vezes são descartados
• Foi compartilhada uma experiência de ter escrito um livro para a Manning em DocBook. Depois da copy editing, tudo voltou em uma única linha, o que foi decepcionante. A pessoa mudou para a autopublicação
• O contato inicial com a O'Reilly começou por e-mail, e foi mencionado que as ferramentas deles são excelentes. É possível gerar a versão completa em formatos compatíveis a partir de commits no git
• Foi mencionado que o formato do livro é adequado para um clube do livro. Os erros renderam bons temas de discussão, e pessoas mais experientes compartilharam como evitaram esses erros
• Muitos dos "erros" do livro servem para apresentar alguns aspectos do Go, como "não usar fuzzing" e "não usar errgroup"
• Foi mencionado que a revisão do Tim foi muito valiosa, mas houve decepção pela falta de uma explicação concreta sobre a revisão
• Outro autor da Manning elogiou o livro, dizendo que há muita informação prática. Pretende consultá-lo novamente ao começar um novo projeto em Go
• Foi levantada uma pergunta sobre um exemplo relacionado a goroutine. A pessoa quer saber se, ao criar um fechamento de função sem usar goroutine, ele ainda faria referência à mesma variável i
• Foi expressado respeito pelo processo do autor de receber feedback e aprender a se comunicar. Também foi mencionada a postura firme diante de uma copy editor problemática
• Foi compartilhada uma experiência de refatoração de uma base legada em C++ na Suíça. Era bom estar em um ambiente onde se podia testar uma nova stack e, se fosse difícil, tentar outra coisa
• Foi mencionada uma coleção de páginas na Sensei's Library sobre erros que aconteceram em Go