一句话总结

我的时间都去哪儿了？（2023 年版）

亮点

• 我在努力弄清自己在 TinyPilot 上把时间浪费在了哪里。
• 我意识到自己又一次对电子邮件上瘾了。
• 我搭建了自己的第一个服务器机架。

目标评分

每个月初，我都会宣布自己想完成的目标。以下是我对这些目标的完成情况：

与新的代工制造商启动一个制造批次

• 结果：第一个制造批次已经启动。
• 评分：A

我已与我们的代工制造商签署了采购订单，所以我们的第一个生产批次已经启动。这将是公司有史以来最大的一次单项变革，令人紧张。如果顺利，那将非常棒；如果不顺利，那将是一场灾难。我希望能是前者。

发布 TinyPilot Pro 2.6.0

• 结果：按计划发布了 TinyPilot Pro 2.6.0。
• 评分：A

我们 6 月的版本发布很顺利，但感觉不太起眼。过去两个版本中，我们的开发精力主要花在让更新更简单、更不容易出错上。这些改动让软件的可维护性显著提高，但这在发布公告里听起来并不激动人心。

营收达到 9.5 万美元

• 结果：营收达到 9.3 万美元。
• 评分：C

TinyPilot 的收入基本持平。虽然有一篇新的评测发布了，但反响平平，所以销量低于我的预期。

TinyPilot 数据

这个月几乎所有指标都持平。我的一个营销尝试效果不佳，但我对其他正在筹备的尝试仍持乐观态度。

TinyPilot 广告的效果大幅下降。5 月时，每 1 美元广告支出能带来 3.64 美元收入。而 6 月，每 1 美元广告支出只能带来 2.62 美元收入。考虑到 2.62 美元的收入中约有 0.90 美元是材料成本，我们的广告仍然盈利，只是利润率变薄了。

我会再给广告一个月的时间。如果表现仍不见好转，我会约 TinyPilot 的营销顾问聊一聊，看看能改进什么。

我的时间都去哪儿了？

在最近的一次独立创始人聚会上，我提到自己最大的挑战是为重要但不紧急的任务挤出时间。

其他与会者都很惊讶。为什么我不能把一切都自动化或委派出去？有什么事情必须由我亲自处理？

去年，我发现评估自己的时间分配很有用，所以今年我再次做这个练习。

以下是我作为 TinyPilot 创始人占用我最多时间的几项工作。

任务 1：协调各项变更

当 TinyPilot 的团队超过两个人时，我意识到我的主要职责之一就是协调各项变更。

TinyPilot 在多个维度上并行发展：我们改进软件、改进硬件、整合新供应商、增加团队成员等等。

对一个领域的改动通常会产生波及效应，影响到其他部分。随着 TinyPilot 的人员规模和复杂度不断增长，这种波及效应也变得更频繁、更显著。

如何减少在这上面花的时间？

聚会上有几位与会者建议我干脆雇一个管理者。这说起来容易做起来难。

TinyPilot 有三个团队，每个团队两到三人：软件开发、支持工程，以及客户服务／本地运营。这三个团队的职责基本互不重叠。

如果我雇一个人只管理 TinyPilot 的其中一个团队，那节省不了多少时间。如果雇一个人管理全部三个团队，那他需要有管理软件的经验，所以年薪可能至少要 12.5 万美元以上。这意味着雇用这个人的总成本每年至少 20 万美元，会吃掉 TinyPilot 目前的全部利润。

我能想到的最好办法和去年一样：同时推进的项目少一些，寻找更多委派的机会。

有些任务我之所以亲自承担，是因为我注意到其中有些部分无法委派。比如，一个任务包含子任务 A、B 和 C，而其中 B 需要代表 TinyPilot 签署合同，我就会想：“哦，只有我能做这件事。”在某些情况下，我本可以把任务 A 和 C 委派出去，但我常常忘了考虑这种可能。

另一个办法是把更多工作交给供应商，缩小 TinyPilot 自己承担的工作范围。今年，我们停止了自己做履约配送，把这项工作转给了一家第三方物流（3PL）供应商。这让处理边缘情况变得更难了，但它彻底消除了我们之前管理的一大类工作。

任务 2：管理与 3PL 合作伙伴的关系

我原以为向 3PL 供应商过渡的工作会高度集中在前期。我知道挑选供应商并完成切换会很困难，但我以为之后基本就一帆风顺了。

我发现，与 3PL 供应商之间仍有一长串琐碎的流程需要摸索：

• 库存从我们的办公室运到 3PL 仓库的过程中，如何跟踪？
• 如何核实 3PL 没有在他们的仓库丢失库存？
• 当 3PL 在订单中发错货时，如何解决？
• 如何处理要求当日发货的客户？

这些都是可以解决的问题，但我们不断遇到新问题，所以我花了很多时间思考 3PL 的事。

如何减少在这上面花的时间？

这方面我应该更多地委派给团队其他成员。

我已经开始让 TinyPilot 的本地员工更主动地参与管理 3PL 的关系，而且这正在奏效。

以前，对于像防止 3PL 丢失库存这类问题，我会自己定义一套审计其库存报告的流程。而现在，我会请本地员工中的一员来做这件事，而不是事事都由我亲自定义。

任务 3：参与软件开发

我在 TinyPilot 的软件开发上花了很多时间，因为这是我最喜欢的部分。尽管已经没什么时间写代码了，但我骨子里仍然是个开发者。

当我有几个小时空闲时，我常常用来修复一个小 bug 或以某种方式整理代码。但有时看似很小的改动会膨胀成好几天的工作量。

如何减少在这上面花的时间？

这条很难，因为显而易见的解决方案是：“Michael 应该停止写代码。”

可我喜欢写代码啊……

更实际的解决方案是，我在接任务时应该更保守。我应该把开发工作限制在：

• 改善开发者体验的工作，比如更好的文档、改进的测试或新的便捷脚本
• 凭借我在公司内的历史知识或背景，由我亲自完成比向别人描述清楚更容易的改动
• 实验性的改动，如果成功会有益处，如果不成功也可以直接扔掉

任务 4：审阅文档

支持工程团队除了提供日常客户支持之外，还负责撰写文档和教程。我对面向公众的文档要求很高，所以花很多时间审阅团队的文字，并就风格、清晰度和技术用语提供反馈。

审阅文档并不占用很多实际时间，但需要我大量的专注力。我发现在自己的写作中做到清晰已经很耗费心力——而阅读别人的文字并准确说出我认为缺少或含糊的地方，对我来说更难。

我常常成为文档任务的瓶颈，因为即使我有一个小时的空闲时间可以审阅新教程，我也常常没有足够的精力给出有用的反馈。

如何减少在这上面花的时间？

我能做的最容易的改变就是更多地依靠同伴评审。在开发团队里，软件工程师之间 90% 的代码互审都不需要我参与。书面英语要协调统一的风格比代码更难，但我认为文档编辑中大约 80% 可以通过同伴评审完成。

另一个我应该做的改变是，在分配文档任务时考虑自己的带宽。我以前会连续往支持工程团队的任务队列里加三个教程，然后自己却没有能力一次性审阅完。我应该把文档任务安排得更分散一些，好给自己留出审阅时间。

戒掉电子邮件成瘾

过去几年，我在与电子邮件保持健康关系和对邮件产生低效成瘾之间反复摇摆。

我是怎么丢掉良好的邮件习惯的？

一旦养成了健康的邮件习惯，通常很容易保持。而打破我健康习惯的，通常是有某个事件给了我一个正当理由去紧盯邮件。

最近，制造 TinyPilot 金属外壳的供应商交货延误，导致我们外壳用完了。外壳断货是个大麻烦，因为它使我们无法组装新设备。这意味着我得手忙脚乱地给本地团队重新分配任务，而且新任务还得是那种几天后（希望如此）外壳到货时可以随时放下不干的活。

在外壳短缺这类情况下，频繁查看邮件确实有其正当性。如果中国的供应商在周五晚上给我发邮件，而我把邮件搁到周一早上才回，他们要到周二早上（中国时间）才能看到我的回复。那就是三天的延误，也就意味着本地团队要多三天无法组装新设备。

问题在于，紧急情况结束后，我却保留了不停查看邮件的习惯。而且当我查看邮件却没发现什么紧急事项时，我仍然渴望那种多巴胺刺激，于是就去刷社交媒体。这从来都不是什么有产出的事。原本 30 秒查看邮件的小憩，变成了 10 到 30 分钟的刷屏消沉。

解决方案 1：只在预定的邮件时间查看邮件

一直以来，我戒除不良邮件习惯的方法是把一天的时间明确规划出来。

每天早上，我把工作日分成 30 分钟的时间块，并决定每个时间块怎么用。为了避免强迫性地查看邮件，我会专门安排阅读和回复邮件的时间，而不是让邮件成为全天背景式的嗡嗡声。

我需要强迫自己重新养成这个习惯。进入节奏之后保持很容易，但进入节奏本身很难。过去，我咬着牙熬过头几天，之后就变得容易起来，回报也足够多，不再需要靠意志力硬撑。

解决方案 2：鼓励事后反馈

写这篇文章时是上午 10 点，今天到目前为止我还没查看邮件。但我心里有一种焦灼感，觉得我在阻碍工作。

我有这种感觉，是因为我的队友们经常向我寻求对支持工单的反馈，而这是我鼓励过的。

我意识到，队友们把支持工单升级给我，会让我收件箱的时效性更强。工单不再只是等两位支持工程师中任何一位有空，而是变成了等我以及那位向我升级工单的特定支持工程师。于是我就觉得必须尽快回复，以免让客户等上好几天。

一个我们从未尝试过的选项是“并行升级”。与其暂停支持工单等待我的反馈，我应该鼓励队友继续与客户沟通，同时向我寻求反馈。

解决方案 3：让队友更多地使用同伴评审

在讨论文档审阅时我提到了同伴评审，但我应该在所有类型的工作中寻找更多同伴评审的机会。它能确保人们在与队友协作中共同成长，也能减少那些专门卡在我身上的任务。

业余项目

搭建我的第一个家用服务器机架

自从搭建了我的第一台 homelab 服务器以来，我的办公室里积累了一堆越来越多、不断增长的服务器和网络设备。

我的未婚妻指出，我的办公室很脏，因为到处都是线，连吸尘都没法吸。我心想：“什么？不，这线是正常数量。”但后来我开始打量它们，发现确实有点太多了……

我想到，搭建一个服务器机架可以让我们俩都开心。我能享受一个有趣的 homelab 项目，她也会喜欢所有线都收进一个独立单元的整洁感。

于是，我搭建了我的第一个服务器机架。搭建过程很有趣，而且它确实让一切整洁了很多。所有设备垂直堆叠后，地上的线少了，整套东西还装了轮子，方便移动清洁。

我第一次使用了管理型交换机和 VLAN。起初，我觉得 VLAN 太繁琐、难以调试。现在掌握了基本用法后，我喜欢上了它，恨不得给所有东西都划分 VLAN。

我正在写一篇更长的文章，介绍我是如何挑选所有组件的，以及我犯了哪些错误，敬请期待。

学习 Nix

Nix 过去一年来一直位居我“看起来很有意思的技术”清单之首，所以我最近投入了一些时间更深入地了解它。

我写了一些关于我初次体验 Nix 的笔记，没想到在 Hacker News 和 Twitter 上获得了大量关注。Nix 社区的人们纷纷联系我，主动帮助我解决卡住的地方。

这些成果鼓励我在实验自己尚未完全理解的技术时，记录更多笔记。

用 Go 造自己的身份认证库

2018 年我开始开发 web 应用时，不想自己实现身份认证，所以一直使用第三方服务。

第三方身份认证服务还算好用，但它们限制了我的开源项目的采用。其他开发者只有使用和我相同的认证服务，才能部署我的应用。

第三方认证的另一个问题是，它会让端到端测试更慢、更不可靠、更复杂。

在我最近的项目 ScreenJournal 中，我想找一种避免使用第三方认证服务的方法。我先调研了有哪些可用的认证库。我的要求是：

1. 必须是开源的。
2. 必须使用 Go，我目前做 web 应用首选的语言。
3. 必须是构建进我应用里的库，而不是与应用并行运行的独立服务。
4. 必须支持 SQLite 作为数据存储。

goth（前身为 gomniauth）似乎是最流行的认证库，但它不满足要求 (3)，因为它依赖外部第三方服务。

另一个流行的 Go 认证方案是 authboss。它满足我的所有要求，但文档相当匮乏。我发现这是作者有意为之的选择，以减少支持请求。

我花了一个下午尝试用 authboss 实现一个简单的 web 应用，但我连最基本的功能都没跑起来。对 authboss 了解得越多，就越觉得它不符合我的需求。它似乎期望集成者不仅用 authboss 做认证，还用它做页面渲染和 URL 路径路由，这超出了我希望一个认证库承担的职责。

现在，我正尝试创建自己的可复用认证库。我并不想把它做成一个流行的开源包，只是想省得我在所有业余项目里复制粘贴一堆认证代码。

到目前为止，它唯一能做的就是检查用户的密码是否正确。它还不能复用，因为客户端仍然得自己创建密码哈希——而我希望这是认证库的职责。

开发一个可复用的认证库是个有趣的挑战，因为它迫使我使用平时不常用的 Go 特性。它也考验我的架构能力，因为我需要在“库把事情简化”与“对不同认证形式保持更灵活”之间权衡取舍。

总结

完成了什么？

• 开始与一家代工制造商合作，生产第一批 TinyPilot Voyager 2a 设备。
• 搭建了我的第一个家用服务器机架。
• 学习了 Nix 和 NixOS 的基础知识。

经验教训

• 作为创始人，我有几个更高效利用时间的机会：
  • 寻找更多委派任务的机会，并把较大的任务拆分以便更容易委派。
  • 在接手开发任务时更加保守。
  • 更刻意地安排花在电子邮件上的时间。
  • 鼓励队友更多地使用同伴评审。
• 服务器机架对 homelab 极客和他们的另一半来说都很有趣。

下个月的目标

• 销售收入达到 9.8 万美元。
• TinyPilot 向代工制造商的转移按计划进行。
• 花在电子邮件上的时间少于 40%。