H3：关于“如何发货”的重要文章
两周前，Sean Goedecke 的这篇重要文章走红，因其对大公司工程师应如何思考发货的道德迷宫-式分析而引发了愤怒和热情：“发货是公司内部的一种社会建构。具体来说，这意味着当公司的重要人物认为项目已发货时，项目就已发货。”
这篇文章让我想起了Zach Holman 2018 年关于“双重发货”的文章，他也提出了同样的观点——发货与其说是一个实际的具体事件，不如说是我们传教的一种社会建构：“我们在早期 GitHub 经常做的一件事是两步发货：基本上，先发布一个大的产品，然后在几天或几周后发布一个较小的附加功能。在第二个发布帖子中，你可以回顾最初的更大的帖子，从而获得两倍的效果。”

H3：职业生涯中应尽早内化的三件事

1. 编写和部署代码的行为更类似于势能而不是动能。
2. 软件开发的理想状态是一个所有利益相关者都能立即全面理解变化和改进的世界；这个理想与现实之间的差距比软件本身更大、更有害、更有价值。
3. 没有人对你正在做的事情的了解、背景甚至基本意识能有你哪怕一小部分。

很容易——也很舒适！——对这类事情持怀疑态度。当然，有一些组织以优先考虑完美发货而闻名——例如谷歌及其以宣传文档为驱动的文化。当然，也有一些组织因为工程文化封闭且协作不足而逐渐衰落甚至消亡。当然，也有优秀的工程师建造了伟大的东西，但因为他们“不够政治化”而被公司淘汰。管理大型技术组织是一个未解决的问题；几乎没有严格正确的答案。

这里有一个稍微不同且更有用的框架：当你在编写代码时，从“为什么”开始——谁关心这个东西，他们为什么关心，他们的成功标准是什么？那个人可能是你（或你团队中的未来工程师）；可能是客户（或一个实际上下个月就打算流失的人）；可能是一位副总裁（他批准这个项目主要是为了多招几个员工）。故意忽视“如果这个东西从未投入生产会发生什么，真正会发生什么？”（或者，相反，“如果这个东西投入生产但从未被使用会发生什么？”）这个答案的道路，是成为一个有能力的“程序员”但没有影响力或文化资本的道路。
（换句话说：你的工作是创造价值，代码是进行中的工作，而不是价值本身。）