一句話總結

我該如何進一步授權？

重點提要

• 我思考如何更有效地授權產品決策與文件工作。
• 我比較學習 Nix 與學習 Zig 的經驗。

目標達成度

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

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

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

我們現在已經有了一套方案，用於在 TinyPilot 客戶更新至最新版本前，確認其授權仍在有效期內。選定第三方授權管理解決方案後（目前傾向於 Keygen），還需補齊一些細節，但主要架構已大致確定。

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

• 成果：我沒有完成這項。
• 評分：F

部分原因是時間有限。我必須臨時處理供應商的幾個問題，花掉了不少時間。

另一個原因是這是一件令人不愉快的工作，所以我拖延了。這件事很重要，因為我們想及早發現製造上的錯誤，但它需要向我們的 3PL(第三方物流) 提出特別要求，而對方以往的配合度並不高。

處理 TinyPilot 年終稅務工作

• 成果：我們已向所有供應商收齊 W-9 表格。
• 評分：A-

這項工作現已完成，我也更清楚哪些對象需要提供 W-9 表格。未來可以避免臨時抱佛腳。

TinyPilot 數據統計

營收較 11 月略微下滑，但這是每年都會出現的季節性趨勢。我們的正常區間大約是每月 7.5 萬至 9 萬美元，目前處於正常範圍的低端，但還不到令人擔憂的程度。

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

不過，我一直把心力放在管理轉向外部製造與履約廠商的過渡上，因此忽略了行銷。幸好過去幾個月 TinyPilot 即使沒有投入太多行銷仍持續成長，但我不能永遠指望這樣，因此我 1 月的目標之一是探索新的行銷管道。

我能授權困難的產品決策嗎？

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

我曾嘗試將困難的產品決策授權給 TinyPilot 團隊，但進展不大。

如果我能做出一張圖表，顯示某個功能的成本與能帶來的使用者滿意度，然後告訴團隊只要維持在線的上方就好，那就太棒了。

但決定對新功能投入多少，還有許多其他考量因素，包括：

• 這個功能是否會對不需要它的使用者造成困惑或介面雜亂？
• 維護這個功能的長期負擔會是多少？
• 這個功能會對我們的支援團隊造成什麼影響？

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

這樣說可能有點自命不凡，但做最終決策的人必須具備「產品願景」。他需要與客戶、開發團隊和支援團隊都保持緊密連結。而在 TinyPilot，唯一處於這個位置的人就是我。

一個可能的解法是聘請一位產品經理，職責是承接高層策略、轉化為計畫並與團隊一起執行。但這不太實際，因為這意味著要多管理一個人，並讓他加入與團隊的所有溝通。我目前管理六個人，這感覺已經是我能有效管理的上限。

另一個可能是讓現有團隊成員兼任產品經理的職責，但這也感覺不切實際。這不只是像早上收信那樣的瑣事——他們必須參與幾乎所有與客戶和團隊的互動，等於每週要多花 10 到 20 小時。即使真的這麼做，我也不確定能否把人訓練到能做出穩健產品決策的程度。

我目前的計畫是繼續向開發團隊提供高層策略，以及用於修復錯誤和開發功能的粗略工時預算。這樣的做法目前運作良好，但我仍在尋找能讓他們更自主做決策的方法。

我能把文件工作授權得更好嗎？

我對文件要求很講究。如果看到可以改進的地方，我會希望改到盡可能好才發布。

我仍會審閱 TinyPilot 所有的部落格文章、常見問題和教學文件，而且我常常是發布流程的瓶頸。我感覺自己作為創辦人的時間有很大一部分都花在審閱文件上。

倒不是說我在文件上花了多少實際時數，而是審閱文件耗用了我大量的「深度思考」額度。我每天大概只能寫作一小時。審閱別人的文字比自己寫作更耗神。因為我不僅要思考如何表達一個想法，還得思考為什麼要選擇那樣表達。

我以前在程式碼審查時也曾為完美主義所苦，後來學會了放過小細節。程式碼就算不是最漂亮也沒關係，因為不會影響使用者體驗。但文件是每個人都會看到的，A 級寫作與 B 級寫作之間有著明顯的差異。

那麼，我該如何在不讓自己成為流程依賴的情況下，維持高標準的寫作品質？

我曾考慮找一位自由接案的技術文件寫手，但那會讓我們的寫作流程變得更複雜。我也擔心專職寫手的存在會讓大家不想精進自己的寫作。他們可能會想：「我隨便寫寫就好，反正修飾是技術寫手的工作。」

我在審閱文字時遇到的一個挑戰是，我腦中對典型的 TinyPilot 客戶有一個想像的模型，但我不知道如何準確地向他人闡述這個模型。即使他人理解了這個模型，也很難寫出符合 TinyPilot 客戶模型的內容。

或許改進的方法之一是回顧過去的審閱紀錄並尋找規律。如果發現規律，我就可以說：「在送審之前，先檢查是否有段落適合加上螢幕截圖，確認是否在使用新術語前已先加以解釋等等。」

我們團隊有訂閱 Grammarly，但它不太符合我們的工作流程。大家或許會在初稿時使用，但沒有人想在每次編輯後都把整篇文章複製貼上到 Grammarly。我研究過以開發者為導向的 Vale，但相較於 Grammarly，它似乎比較陽春。或許我們可以為 Vale 設定一些低干擾的檢查，所以我打算試試看。

學習 Nix 與學習 Zig 的對比

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

以初學者的程度學過兩者後，比較學習 Nix 與學習 Zig 的經驗還滿有意思的。

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

我聽過對 Zig 的抱怨之一是文件寫得很差。我覺得文件確實相當簡潔，而且比較像是從編譯器設計者的角度而非開發者的角度撰寫，但我仍能透過爬梳討論和實際嘗試，建立起對 Zig 準確的心智模型。

使用 Nix 六個月後，我對 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 工具預期略有不同的情況，然後就撞牆了。舉例來說，我到現在還搞不懂如何在 Nix 下執行任意的 Python 專案。

Nix 最令人驚訝的缺口之一是，沒有官方方法可以指定想要安裝的套件版本。這個議題已經討論了八年，似乎既沒有解決方案，甚至也沒有官方表態說明未來是否會修復。

Nix 的領導是去中心化的，Zig 則有 BDFL

Andrew Kelly（安德魯·凱利）是 Zig 的原創者。雖然已有其他人加入專案，但安德魯·凱利實際上仍是終身仁慈獨裁者（BDFL(仁慈獨裁者)）。當我搜尋 Zig 的文件或求助資訊時，經常會看到安德魯·凱利或專案中的官方人士在 GitHub 議題或論壇討論中回覆。

當我初次聽聞 Nix 時，我以為 Eelco Dolstra（艾爾科·多爾斯特拉）會是 Nix 的 BDFL。至少就公開資訊來看，他似乎並不是。

Nix 是艾爾科·多爾斯特拉的創見，源自他2006 年的博士論文。艾爾科·多爾斯特拉是 Nix Foundation 的主席，但他同時也在 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(flake 機制) 的爭議性變革中，這是一項相當新且仍非官方的功能。但所有最新的指南都使用 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（《用 Zig 為 C 應用程式撰寫單元測試》）” 在 Hacker News、Lobsters 和 Ziggit 上頗受歡迎。
• 完成了年終稅務工作。

經驗教訓

• 定期對文件審閱進行後設檢視可能會有所幫助。
  • 我們目前僅就單篇文章討論改進，但透過檢視在多篇文章中反覆出現的模式，或許更能提升團隊的寫作能力。
• Vale 或許有助於在文件審閱前捕捉小問題。

下個月的目標

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

徵求協助

• 如果你曾與服務小量訂單（每月 100 至 200 件出貨）的 3PL 合作且有良好經驗，請告訴我。我正在尋找合適的 3PL。