一句话总结

我怎样才能更多地授权出去？

亮点

• 我思考如何更好地委派产品决策和文档工作。
• 我对比了学习 Nix 与学习 Zig 的体验。

目标评分

每个月初，我都会定下当月想要完成的目标。以下是本月目标的完成情况：

完成 TinyPilot 许可证验证的设计工作

• 结果：设计文档已完成并通过评审。
• 评分：A

我们现在已经有了一套方案，用于在 TinyPilot 客户更新到最新版本之前验证其许可证是否仍然有效。一旦选定第三方许可证管理方案（我们倾向于 Keygen），还需要补充一些细节，但主要部分已经确定。

为每批新设备建立抽检流程

• 结果：我没有完成这项工作。
• 评分：F

部分原因是时间紧张。我不得不临时处理供应商的几个问题，这占用了一些时间。

另一个原因是这项任务不太愉快，所以我拖延了。这件事很重要，因为我们想尽早发现制造错误，但这需要向我们的 3PL(第三方物流) 提出特殊请求，而他们历来不太配合。

处理 TinyPilot 的年终税务工作

• 结果：我们已向所有供应商收齐了 W-9 表格。
• 评分：A-

这项工作现已完成，我也更清楚哪些人需要向我们提供 W-9 表格。以后可以避免把它拖到最后一刻再做。

TinyPilot 数据

收入较 11 月略有下降，但这是每年都会出现的季节性趋势。我们的正常区间似乎是每月 7.5 万至 9 万美元，所以目前处于正常区间的低端，但并不令人担忧。

利润看起来很吓人，是因为我仍在按收付实现制记账，而由于转向第三方代工厂，我们在制造环节的前期投入大幅增加。第四季度，TinyPilot 在物料和制造上花费了 15 万美元，是我们单季度花费最多的一次。按销货成本(COGS)口径计算，TinyPilot 在 12 月的利润实际上是 9000 美元（即正的 9000 美元）。

不过，由于我把精力放在管理向外部制造和履约供应商的过渡上，营销工作有所疏忽。好在过去几个月 TinyPilot 即使没有在营销上投入太多也实现了增长，但我不能永远指望这一点，因此我 1 月的目标之一是探索一些新的营销渠道。

我能把困难的产品决策授权出去吗？

回想最近时间的去向，我发现很大一部分都花在了我所谓的“困难的产品决策”上。这指的是我思考 TinyPilot 需要哪些功能、应在这些功能上投入多少，以及遇到意外时如何重新分配资源的时间。

我曾尝试把这些困难的产品决策授权给 TinyPilot 团队，但进展不大。

如果我能做一张图表，展示某个功能要花多少成本、能带来多少用户满意度，然后告诉团队只要保持在线的上方就好，那就太妙了。

但决定在新功能上投入多少时，需要考虑的因素要多得多，包括：

• 这个功能会不会让不需要它的用户感到困惑或觉得界面臃肿？
• 维护这个功能的长期负担会有多大？
• 这个功能会对我们的支持团队产生什么影响？

即使我能做出这样一张多维图表，也很难对所有变量做出有意义的估算。一个人可能认为 5% 的用户会从某个功能中受益，而另一个同样合理的同事可能估计是 15%。仅这一个变量就会让功能的价值相差 3 倍。把所有变量综合起来，两个人得出的投资回报率估算可能会相差 100 倍。

这么说可能有点自命不凡，但做最终决定的人必须具备“产品愿景”。他需要与客户、开发团队和支持团队都保持紧密联系。而在 TinyPilot，唯一处于这个位置的人就是我。

一个可能的解决方案是聘请一名产品经理，其职责是将高层战略转化为计划并与团队一起执行。但这不太现实，因为这意味着要多管理一个人，并让其融入与团队的沟通中。我目前管理着六个人，这感觉已经是我能有效管理的上限。

另一种可能是让现有团队成员承担产品经理的职责，但这也感觉不切实际。这不仅仅是像早上收邮件那样的额外杂务——他们必须参与几乎所有的客户和团队互动，这意味着每周要多花 10 到 20 小时。即使这样做了，我也不确定能否把人培养到能够做出稳健产品决策的程度。

我目前的计划是继续向开发团队提供高层战略，以及用于修复缺陷和功能开发的大致工时预算。这种方式一直行之有效，但我仍在寻找让他们更自主地做决定的方法。

我能把文档工作更好地授权出去吗？

我对文档要求很挑剔。如果我看到可以改进的地方，就不想在做到最好之前发布。

我仍然会审核 TinyPilot 所有的博客文章、常见问题和教程，而且经常成为发布的瓶颈。我感觉作为创始人，大量时间都花在了文档审核上。

倒不是说我在文档上花了那么多纯粹的工时，而是审核文档占用了我大量“深度思考”的精力。我每天大概只能写一个小时的文章。审核别人的写作比自己写作更耗神。因为我不仅要思考如何表达一个想法，还要思考为什么要这样表达。

我过去在代码评审中也曾受完美主义困扰，不得不学会对小问题放手。代码就算不是尽善尽美也没关系，因为它不会影响用户体验。但文档人人可见，A 级写作和 B 级写作之间存在切实的差距。

那么，如何在不让自己成为流程依赖的情况下保持高写作标准呢？

我曾考虑引入一名自由职业的技术写作者，但这会让我们的写作流程变得更复杂。我还担心专职写作者会让人不愿提升自己的写作水平。他们可能会觉得：“我想怎么写就怎么写，反正技术写作者会来修改。”

我在审核写作时遇到的一个挑战是，我脑海中有一个典型 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 的直接替代品持怀疑态度，但每次我用 zig 替换 gcc 时，一切都能正常工作。Zig 声称你可以直接在 Zig 文件中导入 .c 文件，而确实可以。

我对 Nix 的体验是，Nix 试图做的事情要广泛得多，从像构建 Node.js 项目这样简单的事情，到像构建和管理整个操作系统这样宏大的事情。

当我的项目与 Nix 工具的预期完全一致时，一切都很顺利。但我经常遇到设置与 Nix 工具预期略有不同的情况，这时就会陷入僵局。例如，我至今仍没弄明白如何在 Nix 下运行任意 Python 项目。

Nix 中最令人惊讶的缺口之一是没有官方方法来指定你想安装的软件包版本。这个问题已经讨论了八年，而似乎仍没有解决方案，甚至没有官方表态说明是否会修复。

Nix 的领导是去中心化的，而 Zig 有一位 BDFL

Andrew Kelly（安德鲁·凯利）是 Zig 的最初创建者。后来有其他几人加入了该项目，但安德鲁·凯利实际上仍是 BDFL(终身仁慈独裁者)。当我搜索 Zig 的文档或寻求帮助时，经常会在 GitHub issue 或论坛讨论中看到安德鲁·凯利或项目官方人员的回复。

当我第一次听说 Nix 时，我以为 Eelco Dolstra（埃尔科·多尔斯特拉）会是 Nix 的 BDFL。但至少在公开层面，他似乎并不是。

Nix 是埃尔科·多尔斯特拉的创意，源自他的2006 年博士论文。埃尔科·多尔斯特拉是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 工具在自动修复代码方面做得不错，但并非 100% 准确。

在 Nix 中，我也同样遇到过旧示例的问题。Nix 正处于围绕 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 许可证验证的设计工作。
• 发布了三篇新的博客笔记。
  • “使用 Zig 为 C 应用做单元测试” 在 Hacker News、Lobsters 和 Ziggit 上很受欢迎。
• 完成了年终税务工作。

经验教训

• 对文档审核进行定期的元回顾可能会有帮助。
  • 我们目前只在单篇文章层面讨论改进，但通过回顾多篇文章中反复出现的问题，团队的写作能力可能会得到更大提升。
• Vale 可能有助于在文档审核前捕捉小问题。

下月目标

• 发布年度回顾。
• 联系五位博主探讨 TinyPilot 合作。
• 准备好 2023 年报税所需的记录。

求助

• 如果你曾与服务小订单量（每月 100–200 单）的 3PL 有过良好的合作体验，请告诉我。我正在寻找一家好的 3PL。