一句話總結

手上同時有太多做到一半的任務。

亮點

• 我在尋找方法，減少手上同時進行的半成品數量。
• 我集思廣益，思考如何與更多早期讀者交流。
• 我對 Gleam 語言中的一項設計決策難以接受。

目標達成度

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

為使用者提供更低摩擦的書籍預購方式

• 結果：從 Kickstarter 預購改為 Stripe 付款連結。
• 評分：A

最初的預售是透過 Kickstarter 進行的，所以我本來打算後續的預購也繼續沿用。過了幾個月後，我才發現 Kickstarter 要求顧客必須建立帳號才能買書，這增加了很多阻礙，讓人打退堂鼓。

改用 Stripe 後似乎對銷量有影響，30 天內在 Stripe 上有 22 筆預購，相較之下只用 Kickstarter 時只有 7 筆。不過這不是完全公平的對比，因為改用 Stripe 後我也發布了一個新的試閱章節。

在書籍網站上發布新的試閱章節

• 結果：發布了「如何撰寫吸引人的軟體版本發布公告」
• 評分：A

這篇文章在 Lobsters 上獲得不錯的迴響，在 Hacker News 上表現也很好，但後來被管理員從首頁移除了。我猜是 Hacker News 上的使用者不喜歡其中對行銷的強調，所以把它檢舉掉了。

這個章節收到的實用回饋比以往任何章節都多。很多是負面回饋，但確實很有幫助，因為我覺得那些批評很中肯。我根據回饋修改了文章，討論也讓我產生了兩個新小節的靈感（「簡要介紹你的產品」和「把數字變成圖表」）。

至少與 10 位讀者進行視訊通話

• 結果：與三位讀者進行了視訊通話。
• 評分：D

這項目標遠遠沒達標。部分原因是整個月份我只安排了兩場通話，但另一個問題是，即使有安排通話，也沒能吸引早期讀者來參加。

Refactoring English 數據指標

數據指標回來了！

我以前每個月都會公布財務狀況，但在賣掉 TinyPilot 之後就停了，因為沒什麼值得報告的數字。現在隨著預售開跑，又有相關數據可以分享了。

很高興看到訪客增加帶動了銷量成長，更高興的是銷量的成長幅度超過了訪客的成長。不確定能不能維持下去，但這會是個好指標，代表大家夠喜歡這本書，願意推薦給別人。

如何同時處理更少的草稿？

寫這本書時一個很有效的方法，是每天至少投入一小時做「困難的」寫作。意思是這一小時不能拿來做排版、文法檢查或校對。

這個策略效果很好。六月發表的內容可能比我職涯中任何一個月都多。我為 Refactoring English 電子書新增了三個章節、發布了一個新的試閱章節，還在這個部落格上寫了三 篇 新文章。

這個策略的問題在於，刻意不做較輕鬆的寫作工作，會累積一堆接近完成、只差文法檢查和校對的文章。特別是上個月，我手邊有很多只寫到一半的東西，感覺一直在浪費心力去追蹤哪些已經發布、哪些還需要最後定稿。

我想根本的問題是我一直開新的部落格文章。也許簡單的解法就是，手上有未完成的草稿時，就不要再開新坑。

如何與更多早期讀者交流？

邊寫邊賣 Refactoring English 的好處之一是，願意預購一本還沒寫完的書的人，相對一般讀者來說應該特別熱情。我原本的計畫是頻繁與早期讀者交流，確保這本書能回應他們的疑問，也讓人容易親近。

實際上，我很難與讀者建立聯繫。我曾針對試閱章節發送簡短問卷，也邀請大家回覆回饋，但在約 1,400 位電子報訂閱者和約 250 位預購客戶中，只收到寥寥幾則回應。

我開始舉辦線上視訊活動，也嘗試了不同形式，包含講座、寫作工作坊、Office Hours，以及像讀書會那樣討論熱門的軟體部落格文章。線上活動本身很有趣，參加者也給了我很棒的回饋，但每場只有幾位讀者參加，感覺還是只接觸到極少數人。

另一個有成效的回饋來源是購買一對一編輯回饋的客戶。雖然目前只有三位付費客戶，但與他們合作讓我更清楚目標讀者想解決哪些寫作問題。

基於這些經驗，以下是我想用來與更多讀者交流的點子：

• 在讀者購買後個別聯繫，詢問他們希望從書中學到什麼，以及目前是否符合期待。
• 稍微優化我的寫作顧問服務頁面，讓它更吸引人。
• 為有學習熱忱但負擔不起原價的人，提供折扣的顧問方案。
• 主動聯繫那些在 Hacker News 上持續投稿卻沒什麼迴響的使用者，看看他們是否有興趣付費請我提供回饋。
• 提供「預約我為你的團隊演講」的選項，讓我可以為對方的團隊分享寫作主題並回答問題。

如何改善這本書的行銷？

除了做到一半的部落格文章，還有很多想為這本書做的簡單行銷工作，但我一直沒有安排時間去做，結果它們就一直占據我的腦容量。

以下是我想完成的、唾手可得的待辦事項腦力激盪清單：

• 改善網站。
  • 加上 favicon。
  • 調整介面，讓行動呼籲從「訂閱電子報」改為「購買搶先體驗版」。
  • 改善搶先體驗頁面。
    • 我已經把名稱從「預購」改為「搶先體驗」。
  • 在網站上顯示哪些章節已經可用，而不只是顯示數量。
• 發布一年前錄製的部落客訪談。
  • 這是為我原本計畫重啟的 Hit the Front Page of Hacker News 錄製的，但後來我把那個產品擱置了，一直把訪談壓著沒發，讓我覺得很過意不去，因為當初還請人家特別接受訪問。
• 把網頁版的試閱內容移植到電子書中，並在網站上將那些章節標示為已完成。
  • 大部分我都已經做了，但因為實在很無聊就一直拖著，還有三個章節的網頁試閱版還沒整合進電子書。

用 Gleam 寫程式，以及對平凡 for 迴圈的想念

為了今年學一個新程式語言，我一直在嘗試 Gleam。我用它來解析以前 AOL Instant Messenger 的聊天記錄，長這樣：

Session Start (DumbAIMScreenName:Jane): Mon Sep 12 18:44:17 2005
[18:44] Jane: hi
[18:55] Me: hey whats up
Session Close (Jane): Mon Sep 12 18:56:02 2005

我寫了一篇較長的文章分享我對 Gleam 的初步印象，之後又花了好幾個小時繼續用它寫程式。

在 Gleam 中最難適應的一點就是沒有迴圈可用。Gleam 刻意不提供迴圈，取而代之的是要你使用遞迴函式，或對清單中的每個元素呼叫映射函式。

沒有迴圈這件事，在我嘗試把聊天記錄切成 token 以便解析時造成最多困擾。我在意的分隔符號是 [' ', '\n', '[', ']']。我也在意冒號，但只有在後面緊跟著一個空白時才算，像這樣：': '。

在 Go 這類語言中，我會用 for 迴圈遍歷字串。當遇到空白字元時，我會檢查前一個字元是不是 :，來處理 : 的情況。

在沒有迴圈的 Gleam 中，我最後弄出一個奇怪的決策樹，很多葉節點都在重複同一段複雜的函式程式碼。

我覺得 Gleam 的很多設計選擇都很有意思，當我用「Gleam 的方式」做事時，感覺很優雅，但就迴圈這件事而言，只覺得像是手邊沒有合適的工具可用。

我會繼續嘗試 Gleam，但也打算試試 Elixir 或 OCaml，因為它們有很多我在 Gleam 中喜歡的特性，同時又能解決我的一些痛點。

總結

完成了什麼？

• 發布了「如何撰寫吸引人的軟體版本發布公告」
• 發布了「goHardDrive 外洩數千名客戶的個資」
• 發布了「我對 Gleam 的初步印象」
• 發布了「從 Gleam 呼叫 Elixir 函式庫的簡單範例」
• 為 Refactoring English 電子書撰寫了三個新章節
• 將先前以網頁試閱形式發布的三個章節整合進電子書

經驗教訓

• 當手上已有未完成的文章時，要抵制開新部落格文章的衝動。
• 我應該加倍投入有效的方法，與讀者展開更多對話。

下個月的目標

• 與至少 10 位還沒聊過的讀者對話。
• 清掉累積的行銷點子待辦清單。
• 發布 Refactoring English 的一個新章節。