一句話總結

與其全力揮棒拚全壘打，不如試試觸擊短打？

本月亮點

• 我正在嘗試撰寫低投入、低回報類型的部落格文章。
• 我正在調整自由接案編輯的策略，改為專門與讀過我的書的人合作。
• 我對於登上 Hacker News 首頁機率的直覺，結果大錯特錯。

目標達成評分

每個月初，我都會訂下想完成的目標。以下是這個月的達成狀況：

發布能為 Refactoring English 網站帶來新讀者的內容

• 成果：發表了〈The Software Essays that Shaped Me〉，在前三天吸引了 1.6 萬名讀者
• 評分：B+

雖然順利完成了，但我在這篇文章上花了太多時間，對最終成果也有點不滿意。

發布《Refactoring English》的新章節

• 成果：沒有發布任何新內容
• 評分：F

我寫了新章節的初稿，但沒有發布。結果把比預期更多的時間花在〈The Software Essays that Shaped Me〉和接案編輯的客戶身上。

寫個人化郵件給 20 位未曾聯繫過的讀者

• 成果：只聯繫了兩位新讀者
• 評分：D

我本來想就此算了，覺得主動聯繫讀者已經學不到什麼新東西。但幾天前，我收到一位曾聯繫過的讀者的回信，他說運用從我書中學到的技巧，第一次讓自己的文章登上了 Hacker News 首頁。這顯然非常有價值，也提醒我應該多做這件事。

關於這點，我在下方有進一步的思考。

Refactoring English 數據指標

9 月的網站訪客數和預購收入都有不錯的成長。我希望能形成讀者互相推薦的正向循環，但感覺還沒到那個階段。不過，單月能有將近 1000 美元的收入，還是很不錯。

嘗試觸擊短打

在棒球中，觸擊短打是指將球棒橫在球的路徑上，而不是用力揮棒。好處是比較不容易揮棒落空，缺點是球不會飛得太遠。觸擊短打最多就是讓你上到一壘，但幾乎不可能打出全壘打。

我大部分的部落格文章都是「全力揮棒拚全壘打」型的文章。我投入大量心力，就是想衝上 Hacker News、Reddit 或搜尋結果的第一名。

問題是，這種「拚全壘打」的文章通常要花我一個月才寫得完，所以如果我一邊寫書一邊發文，每寫一篇部落格文章，就得讓寫書進度停擺一個月。

我一直在想，是不是可以改寫一些「短打」型的文章。這樣一來，我只需要讓寫書進度暫停一週，而不是整整一個月。

我並不想把一個值得細細打磨的主題草率帶過。相反地，我想挑一些本來就容易發揮的主題，試試水溫。

我的第一篇短打是〈I Once Appeared in The Old New Thing〉。這篇文章講的是我 22 歲時在第一份正職工作中的一段經歷。我沒有太多深刻的見解可以分享，但覺得這個故事本身滿有趣的。我只花了大約四小時就寫完，以這樣的題材來說，感覺已經很完整了。

接下來的短打是〈The Software Essays that Shaped Me〉。我看過不少人分享自己最喜歡的軟體部落格文章清單，覺得這是個輕鬆又有趣的主題。最棒的是，喜歡優質軟體寫作的人，或許也會對我的書感興趣。

但當我開始寫〈The Software Essays that Shaped Me〉時，它就不再只是篇短打了。我幾乎把整個 9 月都花在它身上。

我本來只想列出我最喜歡的部落格文章就收工，但那樣感覺太無聊了。於是我試著為每篇文章加上簡短的評論。結果一發不可收拾，寫出來的評論比原文還長。為了讓評論寫得有趣，我改了好幾稿，到現在還是覺得不太滿意。

我最後在〈The Software Essays that Shaped Me〉上花了 17 小時，卻從來沒有停下來思考，如果要花這麼多工，到底還值不值得繼續寫下去。

我覺得這篇文章對有在看我部落格的人來說應該滿有趣的。如果是我認識的人發表了影響他至深的文章清單，我也會覺得有趣。但在這篇文章的留言串中，大家也分享了自己的清單，而我發現陌生人的清單完全提不起我的興趣。或許我投入大量心力寫評論，多少彌補了這一點，但我還是覺得，單純列出好文章的清單，本來就很難真的吸引人。

兩篇文章的表現都不錯，都登上了 Hacker News 首頁，不過都是透過second chance pool上去的，感覺比較像是靠技術性擊倒（TKO）獲勝，而不是真正的擊倒勝。

有趣的是，成果幾乎和投入的時間成正比，這跟我平常的經驗不太一樣。

浪費了我的光榮時刻

過去當我的 Refactoring English 相關文章在 Hacker News 上表現不錯時，通常會明顯帶動書籍的銷量。這次〈The Software Essays that Shaped Me〉衝上了第 2 名，還在首頁停留了 11 小時，卻只有一個人購買。

也許在 Hacker News 上看到我文章的人，都已經知道我在寫書了，所以有興趣的人早就已經買了？

我在文章從 Hacker News 首頁掉下來的隔天早上醒來，才突然意識到：我竟然忘了放書籍的廣告！

書籍網站上的所有試讀章節，都會附上一小段自我宣傳，告訴讀者我正在寫一本關於這個主題的書，並可以購買搶先體驗版。

我忘了在這篇部落格文章中加上自我宣傳，所以前 1.4 萬名讀者看了文章，卻完全不知道我在寫書。唉！

我已經更新了部落格的範本，確保以後不可能再漏掉自我宣傳。

調整自由接案編輯的方向

幾個月前，我決定提供自由接案的編輯服務，幫助其他開發者改善他們部落格上的寫作。我的想法是，這是一個機會，可以驗證我在書中解釋概念的方式，是否真的能讓讀者理解。

缺點是這份工作的成本很高。每個案子要花我四到七小時，而且會耗盡我一天的「深度思考」精力，所以同一天很難再進行自己的寫作。我也會有壓力想盡快交件，雖然其實沒有客戶催我。但以我自己的寫作經驗來說，卡在那裡等好幾天才拿到回饋，感覺真的很糟。

一開始，自由接案編輯確實如我所預期的那樣，為我的書帶來了不少好點子。但隨著接的案子越來越多，能為書帶來的靈感卻越來越少。現在，我寫的大部分回饋，其實都是把書中已經寫過的內容，換成針對個人的版本而已。

我還想繼續做編輯，但只想為那些讀過我的書的作者服務。我把費率提高了一倍，現在編輯一篇部落格文章的價格是 400 美元。但對於讀過我的書的讀者，我會提供 90% 的折扣。

打了 90% 折扣後，收不收費其實都差不多，但我還是希望客戶付一點費用，這樣他們也會有投入感。

對於沒讀過書的客戶，我還是會接，但我希望收費要高到讓我覺得，花時間在這上面而排擠到寫書是值得的。400 美元可能還是太低，之後再觀察看看。

為什麼我一直逃避聯繫讀者？

我一直在想，為什麼我老是無法達成聯繫讀者的目標。表面上看起來不難，但它似乎永遠不是最重要的事，所以我一直往後延。

有些事我會拖延，是因為我不喜歡做，但聯繫讀者其實是我喜歡的事。看看不同讀者在做什麼、他們如何應用我的技巧，其實很有趣。

部分原因在於，寄信給讀者需要啟動能量，因為我必須：

1. 到預購讀者名單中查看
2. 找出有個人網站的人（這樣才能寫出個人化的內容）
3. 瀏覽他們的網站以多了解他們
4. 撰寫郵件，並仔細斟酌用詞，避免聽起來像是 AI 生成的

或許我可以先整理一份要聯繫的客戶及其網站清單。這樣當我想主動聯繫時，就不用每次都從零開始。

用 Stripe 寄送購買後郵件的麻煩

有幾位《Refactoring English》的客戶寫信來，困惑地說他們已經付款，卻沒有收到包含書籍連結的郵件。我是透過 Stripe 收款的，Stripe 會在客戶完成付款後將他們重新導向到書籍的網址。如果客戶沒注意到這個重新導向，或是忘了將頁面加入書籤，就會失去存取書籍的管道。

每當有客戶告訴我找不到書籍連結時，我就會在 Stripe 後台翻找自訂購買後郵件的設定，找了幾分鐘後放棄，然後手動把正確的連結寄給客戶。

上個月，我終於靜下心來，仔細搜尋了 Stripe 的文件和論壇文章，結果發現 Stripe 根本沒有提供讓商家自訂一次性付款完成後郵件內容的功能。就我所知，唯一的辦法就是自己架一個網頁伺服器來監聽 Stripe 的 webhook，然後再透過自己的郵件服務商寄信。就因為 Stripe 懶得讓商家自訂付款完成郵件中的任何文字……

對我來說，架一個回應 webhook 的網頁伺服器應該不會太難，但這意味著要把 Stripe、Buttondown 和 Netlify functions 串在一起，而它們各自都有一些惱人的小細節和 bug。尤其是 Stripe。我到目前為止已經花了大約 10 個小時，試圖讓系統在客戶付款後自動寄信，但還是不確定是否真的正常運作。

以下是目前遇到的坑：

• Stripe 的 Go client library 只相容於特定一個版本的 Stripe webhook API。
  • 不，文件裡根本沒說是哪一個版本。自己跑跑看，從 webhook 的失敗訊息中去猜吧！
• 如果你把 Stripe 帳號更新到最新的 webhook API 版本，然後重新發送舊事件的 webhook，Stripe 還是會用舊的 API 版本，即使它聲稱會使用新版本。
• Stripe 的 webhook 請求對於 checkout.session.completed 實際上並不會包含 line_items，即使文件中寫著會有。
  • 這很麻煩，因為這代表除非你另外呼叫一次 API，否則根本無法知道客戶買了什麼。
• Netlify 會默默地把 HTTP 標頭名稱轉成小寫，所以如果你要找 Stripe-Signature: 標頭，就必須改成找 stripe-signature。
• Stripe webhook 的簽署密鑰和你的 Stripe API 金鑰是不同的。

支線專案

以小時為單位拆解 Hacker News 的成功率

我還在擺弄 Hacker News Observer，這個產品我還沒發布，也還不知道該怎麼處理它。目前我只是先收集資料，用來滿足一些對 Hacker News 成功因素的好奇心。

我一直很好奇，一天之中是否有某些時段更容易讓文章登上 Hacker News 首頁，所以我統計了在一天不同時段中，有多少比例的投稿能登上首頁：

我一開始還以為自己程式有 bug，把成功率算得太高了，因為根據我的經驗，能登上 Hacker News 首頁的投稿比例感覺應該低於 12%。但我隨機查看了過去幾天的幾個時段，數據似乎是吻合的。如果我去瀏覽/newest，裡面通常會有 2 到 5 篇曾登上首頁的文章。我發現有一個 30 分鐘的區間，竟有 27% 的投稿都登上了首頁，這讓我很驚訝。

我原本以為週末的成功率會明顯高很多，因為投稿較少。週末的投稿確實比較容易登上首頁，但效果比我想像中小得多。

• 平日：12.1% 的投稿會登上首頁。
• 週末：13.2% 的投稿會登上首頁。

我本來以為會是平日 5% 對上週末 20% 這樣的差距。這讓週末投稿的吸引力降低了，因為登上首頁的機率只高了一點點，但就算成功了，讀者數量卻少了很多。

我想試著像在HN Popularity Contest 中那樣，把資料限定為個人部落格，因為我很好奇個人部落格是否在某些時段有更高的成功機會。

總結

完成了什麼？

• 發表了〈The Software Essays that Shaped Me〉
• 發表了〈I Once Appeared in The Old New Thing〉
• 發表了〈Get xkcd Cartoons at 2x Resolution〉
• 為《Refactoring English》服務了兩位自由接案客戶
• 設定了 webhook 處理器，為《Refactoring English》客戶寄送購買後的郵件
• 為 Hacker News Observer 新增了「依一天中時段區分的成功率」功能
• 開始為 Jellyfin Roku 客戶端程式碼貢獻
• 與 AirGradient 進行了一次通話，討論如何改善公司與社群成員之間的關係

學到的教訓

• 如果一篇原本設定為低投入的文章，結果變成高投入，就要考慮放棄。
• Stripe 不允許你自訂購買後的郵件。
  • 你必須做一堆額外的設定，才能寄信給客戶。

下個月的目標

• 為讀過這本書的讀者設定編輯折扣。
• 建立一份要聯繫的搶先體驗客戶名單。
• 發布新的一章書稿。