一句話總結

我該如何更有效地授權？

本月亮點

• 思考如何更有效地委派產品決策與文件工作。
• 比較學習 Nix 與學習 Zig 的體驗。

目標達成度

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

完成 TinyPilot 授權驗證的設計工作

• 結果：設計文件已完成並通過審核。
• 評分：A

我們現在已經有了計畫，能在客戶更新到最新版本前，確認他們的授權是否仍有效。等選定第三方授權管理方案後（目前傾向採用 Keygen），還需要補上一些細節，但主要的架構已經確定。

建立新裝置每批生產的抽檢流程

• 結果：沒做。
• 評分：F

一部分原因是時間不夠。我臨時需要處理供應商那邊的幾個問題，花掉了不少時間。

另一個原因是這件事本身很棘手，所以我就一直拖延。這件事很重要，因為我們想盡早發現製造上的瑕疵，但它需要向我們的第三方物流（3PL）提出特殊要求，而對方過去一向不太配合。

處理 TinyPilot 年底的稅務工作

• 結果：已向所有供應商收齊 W-9 表單。
• 評分：A-

這項工作已經完成，我也更清楚哪些對象需要提供 W-9 表單。未來就能避免拖到最後一刻才處理。

TinyPilot 營運數據

營收比 11 月略微下滑，但這是每年都會出現的季節性趨勢。我們平常的營收區間大約落在每月 7.5 萬至 9 萬美元，這次算是落在偏低的一端，但還不到需要擔心的程度。

獲利數字看起來很嚇人，是因為我仍採用現金基礎記帳，但由於我們轉向第三方合約製造商，前期在製造上的支出大幅增加。第四季 TinyPilot 在材料與製造上就花了 15 萬美元，是歷來單季最高。如果改以銷貨成本（COGS）為基準計算，TinyPilot 12 月的獲利其實是正的 9 千美元。

此外，我最近把心力都放在管理轉向外部製造與履約廠商的過渡上，行銷方面就疏於經營。好在過去幾個月 TinyPilot 即使沒有什麼行銷投入仍持續成長，但我不能一直指望這樣下去，所以我 1 月的目標之一就是探索新的行銷管道。

我能把困難的產品決策交出去嗎？

回顧最近時間都花在哪裡，我發現有很大一部分都用在所謂「困難的產品決策」上。也就是思考 TinyPilot 需要哪些功能、該投入多少資源，以及遇到突發狀況時如何重新調整優先順序。

我試著把這些困難的產品決策交給 TinyPilot 團隊，但進展不大。

如果能畫出一張圖，清楚呈現某個功能要花多少成本、能帶來多少使用者滿意度，然後告訴團隊「只要做圖中這條線以上的功能就好」，那就太理想了。

但決定要在一項新功能上投入多少，還有許多其他因素要考量，包括：

• 這個功能會不會讓不需要它的使用者感到困惑或覺得介面雜亂？
• 長期維護這個功能的負擔會有多大？
• 這個功能會對客服團隊造成什麼影響？

即使我真能做出這種多維度的圖表，要對所有變數做出有意義的估算也很困難。一個人可能認為只有 5% 的使用者會受惠於某個功能，另一個同樣合理的同事卻可能估計是 15%。光是這一個變數，就讓功能的價值差了三倍。把所有變數加在一起，兩個人的投資報酬率估算甚至可能差到 100 倍。

這樣說可能有點自命不凡，但最終做決策的人必須具備「產品願景」。他必須同時連結客戶、開發團隊與客服團隊。而在 TinyPilot，唯一處在這個位置的人就是我。

一個可能的解法是聘請一位產品經理，負責把高層策略轉化為具體計畫，再與團隊一起執行。但這不太實際，因為這等於要多管理一個人，還得讓他加入團隊的所有溝通。目前我帶六個人，這已經是我能有效管理的上限。

另一個可能是讓現有團隊成員兼任產品經理的職責，但這同樣不太可行。這不像早上順手收個信那樣簡單——他必須參與幾乎所有與客戶和團隊的互動，等於每週要多花 10 到 20 小時。就算真的這麼做了，我也不確定能否把一個人培訓到能做出正確產品決策的程度。

目前的計畫是，我還是會持續給開發團隊高層次的策略方向，以及用於修 bug 和開發功能的工時預算。這套方式目前還算可行，但我仍在尋找能讓他們更自主做決策的方法。

我能把文件工作委派得更好嗎？

我對文件要求很講究。只要看到可以改進的地方，就不想在做到最好之前發布。

我至今仍會審閱 TinyPilot 所有的部落格文章、常見問題和教學文件，也因此經常成為發布流程的瓶頸。我感覺創辦人的時間有很大一部分都花在審閱文件上。

倒不是說我花在文件上的絕對時數特別多，而是審閱文件會大量消耗我的「深度思考」額度。我一天大概只能寫一個小時的東西。而審閱別人的文章，甚至比自己寫還累。因為我不只要思考如何表達一個概念，還得思考自己為什麼要選擇這樣表達。

我過去在程式碼審查上也曾為完美主義所苦，後來學會了放掉一些小細節。程式碼就算沒寫到最漂亮，對使用者體驗也沒有影響。但文件是每個人都看得到的，A 級的寫作和 B 級的寫作，差異非常明顯。

那麼，要如何在維持高寫作標準的同時，又不讓自己成為流程中的瓶頸呢？

我曾考慮找一位特約的技術寫手，但那會讓寫作流程變得更複雜。我也擔心有了專職寫手後，反而會讓大家不願意提升自己的寫作能力。大家可能會想：「反正我隨便寫一寫，技術寫手會幫我改好。」

我在審閱文章時遇到的一個挑戰是，我腦中有一個典型 TinyPilot 客戶的樣貌，但我不知道如何準確地把這個模型傳達給其他人。即使別人理解了這個模型，要寫出符合 TinyPilot 客戶樣貌的內容也很困難。

或許一個改進方法是，回顧過去的審閱紀錄並找出其中的模式。如果能看出模式，我就可以說：「在送審之前，先檢查一下是否有段落適合加上截圖、是否在使用新詞彙前先解釋過，等等。」

我們團隊有訂閱 Grammarly，但它不太符合我們的工作流程。大家或許會在初稿時用一下，但沒有人想在每次修改後，都把整篇文章複製貼上到 Grammarly 再檢查一次。我有研究過 Vale，它比較偏向給開發者用的，但感覺比 Grammarly 陽春許多。或許可以幫 Vale 設定一些低干擾的檢查規則，所以我打算試試看。

學習 Nix 與學習 Zig 的比較

把 TinyPilot 的製造與履約外包給第三方廠商的好處之一，是我多了時間與心力去學習新技術。過去兩年我一直在遠觀的兩項技術是 Nix 和 Zig，而在 2023 年底，我終於有機會兩者都試了一下。

兩者都學到入門程度後，比較學習 Nix 和學習 Zig 的體驗還挺有意思的。

我學 Zig 靠推理，學 Nix 靠複製貼上

我聽過有人抱怨 Zig 的文件很差。我覺得它的文件的確很簡略，而且比較像是從編譯器設計者的角度撰寫，而非開發者的角度，但我仍然能透過翻找討論串和實際嘗試，慢慢建立起對 Zig 準確的心智模型。

用了六個月的 Nix，我對它的心智模型還是很糟。我讀過好幾種解釋，但概念始終無法在我腦中具體化。每次要寫 Nix 檔案，我只能複製現成的範例再稍作修改。檔案裡大部分都是樣板程式碼，而我根本不理解為什麼要那樣寫。

在 Zig 遇到錯誤時，我通常能推理出編譯器想告訴我什麼。但在 Nix 遇到錯誤時，我就完全束手無策。

我想一個主要差異在於，我在 C 風格語言上有豐富的開發經驗，卻完全沒有純函數式語言的經驗。Zig 是針對 C 和 C++ 開發者設計的，所以對有十年相關經驗的我來說，概念很好理解。

Nix 則深受 Haskell 與其他函數式語言的啟發，那些語言我從沒學過。對 Haskell 開發者來說，Nix 可能會更直觀，而他們反而可能會對 Zig 圍繞指標與記憶體配置器的設計感到困惑，因為那些在函數式語言中並不常見。

Zig 的開發體驗窄而深，Nix 則廣而淺

Zig 目前還沒有套件管理或程式碼覆蓋率的工具。我對 Zig 感到失望的一點是，它對微控制器的支援似乎幾乎付之闕如。

但只要是 Zig 宣稱能做到的事，它都做得很好。我原本對它號稱能無縫取代 gcc 半信半疑，但每次我把 gcc 換成 zig，結果都一切正常。Zig 說你可以直接在 Zig 檔案中匯入 .c 檔案，也的確可以。

我對 Nix 的體驗是，Nix 試圖做的事情廣泛得多，從簡單如建置 Node.js 專案，到宏大如建置與管理整個作業系統都包辦。

當我的專案完全符合 Nix 工具預期的情境時，一切都很順利。但只要我的設定與預期稍微不同，就會直接卡關。例如，我到現在還是搞不懂如何在 Nix 底下執行任意的 Python 專案。

Nix 最讓人驚訝的缺口之一，是竟然沒有官方方法可以指定想要安裝的套件版本。這個議題已經討論了八年，卻似乎沒有解法，甚至連官方是否會或不會修復都沒有明確表態。

Nix 領導分散，Zig 有 BDFL

Andrew Kelly 是 Zig 的原創者。有幾位開發者後來加入了專案，但 Andrew 實際上仍是終身仁慈獨裁者（BDFL）。當我搜尋 Zig 的文件或求助時，經常會看到 Andrew 或其他專案核心成員在 GitHub issue 或論壇討論中親自回覆。

當我第一次聽說 Nix 時，我以為 Eelco Dolstra 會是 Nix 的 BDFL。至少在公開層面上，他似乎不是。

Nix 是 Eelco 的心血結晶，源自他 2006 年的博士論文。Eelco 是 Nix 基金會的主席，但他同時也在 Determinate Systems 工作，這是一家推廣 Nix 的第三方顧問公司。但 Determinate Systems 明確是第三方，並非 Nix 核心。他們發布的東西有時會與 Nix 內部團隊的工作產生衝突而引發爭議。

Zig 給人的感覺是中央集權規劃，Nix 則像是無舵之舟。當我遇到問題找不到答案時，搜尋結果往往是 GitHub 或 Nix Discourse 論壇上冗長的討論。那些對話聽起來就像大家在討論一項我們意外發現的外星科技。而我從沒看過 Nix 核心團隊的人出來發表意見，甚至不確定到底有沒有核心團隊。

在 Nix 或 Zig 裡，舊的解法通常行不通

Zig 尚未發布穩定的 1.0 版本，所以編譯器更新帶來破壞性變更很常見。在 Zig 0.8.0 能跑的程式碼，到了 Zig 0.11.0 可能就失效了。以我的經驗，Zig 的工具在自動修正程式碼方面做得不錯，但並非百分之百準確。

在 Nix 我也遇到類似的舊範例失效問題。Nix 正處在一場圍繞 flakes 的典範轉移之中，flakes 是一個相當新且仍非官方的功能。但所有最新的指南都在用 flakes，而所有舊的討論都沒用 flakes，所以我很難把 flakes 之前的解法套用到我現在的 flakes 環境中。

Zig 需要全團隊投入，Nix 則容易局部採用

Nix 的一個優點是它是自成一體的。我可以在專案裡丟一個 flake.nix 來自動管理相依套件，而不需要改變其他任何東西或要求隊友做什麼。

即使我是團隊中唯一使用 Nix 的人，flake.nix 對我來說仍然很有價值，而且不會給其他人帶來任何成本或要求他們使用新工具。這就像在專案中加入一個 .vscode 目錄：對用 VS Code 的人有幫助，對其他人也沒什麼干擾。

另一方面，Zig 則需要承諾與全團隊的投入。如果你有一個 C 或 C++ 專案，想改用 Zig，你無法只是自己享受更好的工具、等隊友慢慢加入。一旦你在專案中引入 Zig 程式碼，每個人都必須改用 Zig 編譯器來建置，而不是原本的 C/C++ 編譯器。

這不是 Zig 的錯，但這意味著我只有在造訪 Zig 的世界時——像是動手寫點程式或查看 Zig 專案——才會接觸到 Zig，而現在我走到哪都把 Nix 帶在身邊。

總結

完成了什麼？

• 完成了 TinyPilot 授權驗證的設計工作。
• 發布了三篇新的部落格短文。
  • 〈Using Zig to Unit Test a C Application〉在 Hacker News、Lobsters 和 Ziggit 上受到歡迎。
• 完成了年底的稅務工作。

經驗與收穫

• 定期對文件審閱進行後設檢視可能會有幫助。
  • 我們目前只針對單篇文章討論改進，但如果檢視橫跨多篇文章反覆出現的模式，或許更能提升團隊的寫作能力。
• Vale 或許能在文件審閱前幫忙抓出一些小問題。

下個月的目標

• 發布年度回顧。
• 聯繫五位部落客洽談 TinyPilot 合作。
• 備妥 2023 年報稅所需的資料。

尋求協助

• 如果你曾與適合小量出貨（每月 100 至 200 件）的 3PL 合作且體驗不錯，歡迎告訴我。我正在尋找合適的 3PL。