一句話總結

與其全力揮棒追求全壘打，不如試試短打會怎麼樣？

重點提要

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

目標成績

每個月月初，我都會宣告當月想完成的目標。以下是本月的達成狀況：

發表能為《重構英文》網站吸引新讀者的內容

• 結果：發表了 〈形塑我的那些軟體好文〉，在最初三天內吸引了 1.6 萬名讀者
• 成績：B+

這項算是成功達成了，但我在這篇文章上花了太多時間，而且對最終成果有點不夠滿意。

發表《重構英文》的新章節

• 結果：沒有發表任何新內容
• 成績：F

我寫了新章節的初稿，但沒有發表。結果在〈形塑我的那些軟體好文〉和接案編輯的客戶身上花了比預期更多的時間。

寫個人化郵件給 20 位從未交流過的讀者

• 結果：只寄信給了兩位新讀者
• 成績：D

我本來想就此作罷，認為透過聯繫讀者已經學不到什麼新東西了。但幾天前，我收到一位曾聯繫過的讀者回信，他說他運用從我書中學到的技巧，第一次讓自己的文章登上了 Hacker News 首頁。所以，這無疑是非常有價值的，也告訴我應該多做這件事。

我在下方對此有更多思考。

《重構英文》數據指標

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

嘗試短打

在棒球中，短打是指將球棒橫在球的路徑上，而不是用力揮棒。好處是比較不容易揮空，但缺點是球不會打得很遠。短打最好的結果頂多是上一壘，但幾乎不可能靠短打打出全壘打。

我的大多數部落格文章都是「全力揮棒」型的文章。我投入大量心力，因為我想衝上 Hacker News、reddit 或搜尋結果的第一名。

問題是，這種「全力揮棒」型的文章我得花大約一個月才能寫完，所以如果我在寫書的同時還要發表部落格文章，每寫一篇就得讓寫書進度停擺一個月。

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

我不想把一個值得細心琢磨的主題草率帶過。相反地，我想挑一個容易發揮的主題，試試看表現如何。

我的第一次短打是 〈我曾出現在《The Old New Thing》〉。這篇文章談的是我 22 歲時在第一份正職工作中的經歷。我沒有太多深刻的見解可以分享，但我覺得這是一個有趣的故事。我花了大約四小時就寫完了，而且以它的性質來說，我覺得已經很完整了。

我的下一次短打是 〈形塑我的那些軟體好文〉。我看過其他人分享他們最喜愛的軟體部落格文章清單，覺得這是一件輕鬆又有趣的事。最棒的是，欣賞優秀軟體寫作的人，或許也會對我的書感興趣。

當我開始寫〈形塑我的那些軟體好文〉時，它就不再只是短打了。我最後幾乎花了整個 9 月在上面。

我原本只想列出我最喜歡的部落格文章就收工，但那樣感覺太無聊了。於是，我試著為每篇文章加上簡短的評註。接著一發不可收拾，結果寫出的評註比原文還長。我改了好幾稿才釐清怎樣的評註才有趣，而且到現在我仍覺得不算真正成功。

我最後在〈形塑我的那些軟體好文〉上花了 17 小時，卻從未停下來評估是否還值得花這麼多功夫去寫。

我覺得這篇文章對有在看我部落格的人來說是有趣的。如果我認識的人發表了一份影響他的文章清單，我會覺得很有趣。但在這篇文章的留言串中，大家也分享了自己的清單，而我發現陌生人的清單完全引不起我的興趣。或許我透過投入大量心力寫評註，稍微抵銷了這個問題，但我就是覺得，一份優秀部落格文章的清單再怎麼樣也不會太有趣。

兩篇文章的表現都不錯。它們都登上了 Hacker News 首頁，不過都是透過 second chance pool(第二機會池)上去的，感覺有點像靠技術擊倒（TKO）取勝，而不是真正的擊倒獲勝。

有趣的是，成果幾乎與我投入的心力成線性比例，這在平常倒不常見。

錯失了我的高光時刻

過去，當我有一篇《重構英文》的文章在 Hacker News 上表現亮眼時，就會有明顯的讀者購書成長。這次，〈形塑我的那些軟體好文〉衝上了第 2 名，並在首頁停留了 11 小時，卻只有一個人購買。

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

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

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

我忘了在部落格文章中加入自我宣傳，所以最早的 1.4 萬名讀者看了我的文章，卻完全不知道我在寫書。哎呀！

我已經更新了部落格的範本，讓自己未來不可能再忘記加入自我宣傳。

調整接案編輯的做法

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

缺點是編輯的成本很高。每個案子要花我四到七小時，而且會耗盡我一天的「深度思考」額度，所以同一天很難再進行自己的寫作。我也感受到要快速交件的壓力，雖然沒有人要求我趕工。但以我對自己寫作流程的了解，卡住好幾天等回饋是很痛苦的。

一開始，接案編輯確實如我所預期的那樣，為我的書帶來了不少好點子。隨著接案量增加，我從中獲得的新點子越來越少。現在，我寫的大部分回饋，基本上都是把書中已經寫過的內容，改寫成個人化的版本。

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

打了 90% 的折扣後，幾乎等於不收費了，但我還是希望客戶付一些費用，讓他們也覺得自己有投入成本。

我仍會接沒有讀過這本書的客戶，但我希望收費要高到讓我覺得值得犧牲寫書的時間。400 美元可能還是太低，但就先試試看吧。

為什麼我一直跳過讀者聯繫？

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

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

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

1. 打開我的預付讀者名單
2. 找出其中有網站的人（這樣我才能說些個人化的話）
3. 瀏覽他們的網站以更了解他們
4. 撰寫郵件並仔細措辭，避免聽起來像是 AI 產生的

如果我先整理出一份要聯繫的客戶及其網站清單，可能會有所幫助。這樣，當我想聯繫時，就不用每次都從零開始。

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

有幾位《重構英文》的顧客寫信給我，困惑地表示他們已經付款，卻沒有收到附有書籍連結的電子郵件。我透過 Stripe 收款，而 Stripe 會在顧客完成付款後將他們重新導向至書籍的網址。如果顧客沒有注意到這個重新導向或忘記將頁面加入書籤，就會失去存取書籍的權限。

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

上個月，我終於坐下來仔細搜尋 Stripe 的文件和論壇文章，卻找不到任何可以自訂顧客完成一次性付款後 Stripe 所寄送電子郵件的方法。就我所知，唯一的選項是自己架設一個網頁伺服器來監聽 Stripe webhook(網路鉤子)，然後透過自己的電子郵件服務商自行寄信。就因為 Stripe 懶得讓商家自訂付款完成電子郵件中的任何文字……

架設一個網頁伺服器來回應 webhook 應該對我來說不該那麼難，但這意味著要把 Stripe、Buttondown 和 Netlify functions 串接起來，而它們各自都有一些小陷阱和臭蟲。尤其是 Stripe。我到目前為止已經花了大約 10 小時，只是想讓顧客付款後能收到電子郵件，而且還不確定是否真的正常運作。

以下是目前遇到的陷阱：

• Stripe 的 Go client library 僅相容於單一版本的 Stripe webhook API。
  • 不，文件裡沒有說是哪一個版本。執行後從 webhook 失敗中自己去發現吧！
• 如果你將 Stripe 帳號更新到最新的 webhook API 版本，然後重新發送先前事件的 webhook，Stripe 仍會使用舊的 API 版本，即使它聲稱會使用新版本。
• Stripe 針對 checkout.session.completed 的 webhook 請求實際上並未包含 line_items，儘管文件中有提到。
  • 這很麻煩，因為這表示除非你另外呼叫一次 API，否則無法知道顧客買了什麼。
• Netlify 會默默地將 HTTP 標頭名稱轉為小寫，所以如果你在找 Stripe-Signature: 標頭，就必須改找 stripe-signature。
• Stripe webhook 簽署密鑰與你的 Stripe API 金鑰不同。

支線專案

按小時拆解 Hacker News 的成功率

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

我長期以來好奇的一件事是，是否在一天中的某些時段，貼文比較容易登上 Hacker News 首頁，於是我彙整了一天中不同時段貼文登上首頁的百分比：

一開始，我以為自己有個會高估成功率的臭蟲，因為根據我的經驗，Hacker News 貼文登上首頁的比例感覺比 12% 還低。接著，我看了過去幾天的一些隨機區間，發現似乎是吻合的。如果我瀏覽 /newest，通常會有 2 到 5 則曾登上首頁的故事。我發現幾天前的一個 30 分鐘區間有 27% 的投稿登上了首頁，這令人驚訝。

我以為週末的成功率會顯著高於平日，因為投稿數量較少。週末的貼文確實比較容易登上首頁，但影響比我想像的小得多。

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

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

我想試著像在 HN Popularity Contest 上那樣，將資料限縮至個人部落格，因為我很好奇個人部落格是否在特定時段有更好的機會。

總結

完成了什麼？

• 發表了 〈形塑我的那些軟體好文〉
• 發表了 〈我曾出現在《The Old New Thing》〉
• 發表了 〈取得 xkcd 漫畫的 2 倍解析度〉
• 為《重構英文》完成了兩位接案客戶的編輯工作
• 設定了 webhook 處理器，為《重構英文》的顧客寄送購買後的電子郵件
• 為 Hacker News Observer 新增了「依時段顯示成功率」的功能
• 開始為 Jellyfin Roku 客戶端貢獻程式碼
• 與 AirGradient 進行了一次通話，討論如何改善公司與社群成員之間的關係

學到的教訓

• 如果一個低投入的貼文結果變成高投入，要考慮放棄。
• Stripe 不允許你自訂購買後的電子郵件。
  • 你必須做一堆其他事情才能寄電子郵件給顧客。

下個月的目標

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