Câu chuyện phía sau cuốn sách "100 lỗi thường gặp và giải pháp trong Go"

• Đây là câu chuyện tập trung vào cơ duyên gắn bó với ngôn ngữ Go và hành trình cá nhân dẫn đến việc viết sách
• Bắt đầu từ thành công của một bài blog, tác giả ký hợp đồng với Manning và hoàn thành cuốn sách trong suốt 3 năm
• Bài viết mô tả sinh động vô số lần thử sai, những dao động cảm xúc, đặc biệt là xung đột trong quá trình biên tập

Cuộc gặp đầu tiên với ngôn ngữ Go và bước ngoặt

• Năm 2018 tại Thụy Sĩ, sau khi làm PoC bằng Scala/Akka, tác giả bị cuốn hút bởi tính hiệu quả và sự ngắn gọn của Go
• Khi làm việc với Go ở công ty mới và tích lũy kinh nghiệm thực tế, tác giả nhận ra đồng nghiệp liên tục lặp lại những sai lầm giống nhau nên bắt đầu viết bài blog
• Bài blog đăng trên Medium bất ngờ nhận được phản hồi rất lớn, từ đó tác giả có thêm tự tin với việc viết lách

Khởi đầu xuất bản sách: từ ý tưởng đến hợp đồng

• Từ mạch nội dung nối tiếp bài blog, tác giả lên kế hoạch mở rộng thành sách bằng cách thu thập 100 trường hợp lỗi trong Go
• Chỉ gửi đề xuất xuất bản cho duy nhất Manning và nhanh chóng nhận được phản hồi tích cực qua một email ngắn gọn
• Nhận phản hồi tích cực từ 7 reviewer bên ngoài và chính thức ký hợp đồng vào tháng 12 năm 2020

Quá trình viết và cộng tác với các biên tập viên

• Sau khi xác định ‘độc giả đủ điều kiện tối thiểu (MQR)’, tác giả mạnh dạn lược bỏ những nội dung cơ bản không cần thiết
• Trong quá trình cộng tác với biên tập viên phát triển (DE) không chuyên kỹ thuật, tác giả đã cải thiện kỹ năng viết của mình
• Có những chương đã được viết lại hơn 10 lần thông qua quá trình review và chỉnh sửa lặp đi lặp lại

Review bên ngoài và việc tiếp nhận phản hồi

• Cuốn sách được chia thành 3 giai đoạn (1P, 2P, 3P) để thực hiện review kỹ thuật bên ngoài, và điểm đánh giá tăng dần qua từng giai đoạn
• 1P: 13 reviewer, điểm trung bình 4,10 → 2P: 4,15 → 3P: đạt 4,6
• Nguyên tắc tiếp nhận phản hồi xuất phát từ lời khuyên của Bill Kennedy: “đừng bỏ qua dù chỉ một phản hồi”

Khủng hoảng lớn trong quá trình biên tập

• Biên tập viên kỹ thuật được chỉ định ban đầu (TDE) gây bất mãn vì thiếu cả kiến thức cơ bản về Go
• Hệ thống hiệu đính phức tạp và cách cộng tác kém hiệu quả, thậm chí biên tập viên còn chèn vào hàng loạt lỗi
• Quá thất vọng, tác giả tuyên bố dừng công việc, nhưng Manning đã nhanh chóng chỉ định biên tập viên mới để giải quyết vấn đề

Hành trình đến khi hoàn thành và cảm giác trống rỗng sau xuất bản

• Sau khi mọi thứ kết thúc, thay vì cảm giác “xong rồi”, tác giả lại thấy trống rỗng ập đến (trầm cảm sau xuất bản)
• Năng lượng và cảm xúc đã dồn vào suốt gần 3 năm bỗng chốc biến mất trong khoảnh khắc
• Sau đó tác giả dần hồi phục và lấy lại niềm tự hào về nội dung mình đã tạo ra

Thành công của cuốn sách và phản ứng từ cộng đồng

• Ngay sau khi xuất bản, không cần quảng bá dài hơi, cuốn sách đã được chia sẻ tự phát trên Reddit, Twitter và các nơi khác
• Sau 1 năm, tác giả cung cấp nội dung tóm tắt miễn phí qua trang mã nguồn mở 100go.co
• Phía Manning cũng phản hồi tích cực và còn đề nghị một vai trò hỗ trợ tác giả trong tương lai

Tiền bản quyền, doanh thu và ý nghĩa vượt lên trên tiền bạc

• Tính đến cuối năm 2024, bản tiếng Anh đã bán được 11.452 bản, mang về tổng doanh thu khoảng $47,000
• Thu nhập tính theo giờ là thấp, nhưng tác giả đặt ý nghĩa lớn hơn vào đóng góp cho cộng đồng và thành tựu cá nhân thay vì tiền bạc
• Cuốn sách cũng ảnh hưởng đến các series tiếp theo về Java, C++, SQL Server và nhiều chủ đề khác

Lời kết và quyết tâm cá nhân

• Điểm Goodreads đạt 4,66, vượt mục tiêu ban đầu
• Có thể đây không phải là cuốn sách Go hay nhất, nhưng tác giả tin chắc đó là cuốn sách tốt nhất mà mình có thể làm ra vào thời điểm ấy
• Tác giả cũng đã nhận được đề nghị làm bản 2 và hiện đang chờ phản hồi từ độc giả

[zihado]

https://product.kyobobook.co.kr/detail/S000211704725
Là cuốn sách này đây

[GN⁺]

Ý kiến trên Hacker News

• Đã giải thích và đề xuất cải thiện quy trình review theo thiết lập dựa trên PR, nhưng phía bên kia không muốn thử. Mong muốn quá trình cộng tác trơn tru và hiệu quả hơn
• Thật ngạc nhiên khi biên tập viên ngôn ngữ lại quen dùng git hơn công cụ review trên web. Đặc biệt là khi họ đang review một cuốn sách về Go nhưng có vẻ không hiểu rõ về Go
• Cảm thấy khá lạ khi Manning có biên tập viên ngôn ngữ riêng
• Chia sẻ trải nghiệm tiêu cực với Manning. Đang viết sách và tự xuất bản, đã hỏi về khả năng đề xuất bản in lần hai cho Manning. Họ trả lời rằng đã từ chối đề xuất đó
• Chỉ nhắc đến Google Docs như một định dạng tài liệu, nhưng theo bài đăng blog thì có vẻ họ cũng chấp nhận AsciiDoc
• Đề cập đến vấn đề liên quan đến sync.Pool và chia sẻ liên kết liên quan
• Nếu xem cách thư viện chuẩn của Go dùng sync.Pool, có thể thấy nhiều tiered pools với kích thước khác nhau, và các mục có kích thước lớn thường bị loại bỏ
• Chia sẻ trải nghiệm từng viết sách cho Manning bằng DocBook. Sau khi copy editing xong, toàn bộ nội dung bị trả về thành một dòng nên rất thất vọng. Sau đó đã chuyển sang tự xuất bản
• Lần liên hệ đầu tiên với O'Reilly bắt đầu qua email, và có nhắc rằng công cụ của họ rất tốt. Có thể tạo ra phiên bản đầy đủ ở định dạng được hỗ trợ từ git commit
• Nhận xét rằng định dạng của cuốn sách rất phù hợp cho book club. Các "lỗi sai" trở thành chủ đề thảo luận hay, và những người có kinh nghiệm chia sẻ cách họ đã tránh các lỗi đó
• Nhiều "lỗi sai" trong sách thực chất là phần giới thiệu một số khía cạnh của Go, ví dụ như "không dùng fuzzing" và "không dùng errgroup"
• Nói rằng bài review của Tim rất có giá trị, nhưng thất vọng vì không có mô tả cụ thể nào về nội dung review
• Một tác giả khác của Manning khen cuốn sách và nói rằng nó có nhiều thông tin thực tiễn. Họ dự định sẽ tham khảo lại khi bắt đầu một dự án Go mới
• Đặt câu hỏi về ví dụ liên quan đến goroutine. Tò mò liệu nếu tạo closure của hàm mà không dùng goroutine thì có tham chiếu đến cùng biến i hay không
• Bày tỏ sự tôn trọng đối với quá trình tác giả tiếp nhận phản hồi và học cách giao tiếp. Cũng nhắc đến việc tác giả đã giữ thái độ cứng rắn với biên tập viên có vấn đề
• Chia sẻ trải nghiệm refactor một codebase C++ legacy ở Thụy Sĩ. Môi trường ở đó rất tốt vì có thể thử stack mới, và nếu khó thì lại thử hướng khác
• Nhắc đến Sensei's Library có một tập hợp các trang về những lỗi từng gặp trong Go