Shipping is the foundation交付是基础

There are lots of skills involved in being a successful engineer at a big tech company. Running effective meetings, writing good design docs, fleshing out tickets and epics, improving team processes, tech leading small groups of engineers, and so on. But all of these rest on the foundation of being able to ship.在大厂成为一名成功的工程师，需要掌握许多技能。例如：高效主持会议、撰写出色的设计文档、细化任务和史诗级项目、改进团队流程、领导小规模工程师团队等等。但所有这些技能，都建立在能够交付成果这一基础之上。

In Dota 2, the early game involves “laning”: competing with an enemy player to collect resources from a small area. There are many, many strategies and considerations involved in laning. But the simplest possible approach is just to run at your opponent and attack them until they’re forced to either run away or die. All the other laning strategies must solve that problem first, because it doesn’t matter how well you play if you’re forced out of the playing area. If you get that wrong, it doesn’t matter how much else you get right.在《Dota 2》中，游戏前期涉及“对线”：即通过与敌方玩家竞争，从有限的区域内获取资源。对线涉及许多策略和考量，但最简单直接的方法就是冲向对手并持续攻击，直到对方被迫逃跑或死亡。其他所有对线策略都必须首先解决这个问题，因为如果你被赶出了比赛区域，无论你操作水平多高都无济于事。如果这一点没做好，其他方面做得再好也于事无补。

In Magic: the Gathering and Starcraft, many players adopt an “aggro” strategy of building an attacking force as early as possible before the enemy player has time to construct a defense. That constrains the entire strategy space of the game, because it doesn’t matter how clever your plan is if it loses to aggro every time. Even when there are no aggro players in the game, the aggro strategy still shapes how the game unfolds, because the players must still design their decks and play as if they might have to deal with an early attack.在《万智牌》和《星际争霸》中，许多玩家会采取“快攻”（aggro）策略，即在敌方玩家有时间建立防御之前，尽早集结攻击力量。这限制了整个游戏的策略空间，因为如果你的计划每次都会输给快攻，那么无论你的计划多么巧妙都毫无意义。即使游戏中没有快攻型玩家，快攻策略依然会影响游戏的走向，因为玩家在设计卡组或制定打法时，仍必须考虑到可能面临的早期突袭。

In tech companies, shipping is the equivalent of these aggressive strategies. Almost everything you might do — writing a ticket or a design doc, delegating a task to another engineer, etc — should be compared to the default strategy of just sitting down and making the change yourself. That’s why it’s critical to be able to ship: so you can just do trivial things without having to pay the coordination cost.在科技公司，交付就等同于这些快攻策略。你所做的几乎每一件事——撰写任务单、编写设计文档、将任务委派给其他工程师等——都应该与“直接动手亲自完成变更”这一默认策略进行比较。这就是为什么能够交付至关重要：这样你就可以处理琐碎事务，而无需支付额外的协调成本。

If you’re leading a project but you can’t ship, you will inevitably experience a series of dysfunctions:如果你在领导一个项目但无法交付，你必然会经历一系列功能失调：

• Taking fifteen minutes to estimate a task that could be done in five minutes花费十五分钟去评估一个五分钟就能完成的任务
• Suggesting designs that are un-shippable¹, causing hours or days to be wasted on work that can never be successful提出无法交付的设计方案，导致数小时甚至数天的时间浪费在注定无法成功的任务上
• Being unable to sanity-check how long a piece of work will take, which inevitably leads to grotesquely bloated estimates as everyone tries to be cautious无法对工作所需时间进行合理的预判，这不可避免地导致估时变得极其臃肿，因为每个人都在试图采取保守策略
• Frustrating the hell out of any engineers working with you who can actually ship, which is itself a cause of more dysfunction²让那些真正有交付能力的合作工程师感到无比沮丧，而这本身又是引发更多功能失调的原因
• Blowing out trivial tasks into grand projects将琐碎的任务夸大成宏大的项目

That last point is worth special attention. Senior and staff engineers routinely get asked to do lots of different things. The more successful they are, the more they get asked to do. It is crucial that you can deliver easy asks immediately, for a few reasons.最后一点值得特别关注。资深工程师和主任工程师经常会被要求处理各种不同的事情。他们越成功，被要求做的事情就越多。能够立即交付简单的请求至关重要，原因有几点。

First, the volume of requests your managers ideally want to give you is very high. If you turn every task into a slow project that requires multiple engineers, you will simply not get enough done. Second, resourcing projects can be a slow and painful process. Half the point of managers asking you for things is to do an end-run around that process: it’s the fast, illegible alternative to going through ordinary channels. If you can’t knock out the solution quickly on your own, that defeats the purpose entirely.首先，管理层理想中希望交给你的任务量非常大。如果你把每项任务都变成需要多名工程师参与的缓慢项目，你将无法完成足够多的工作。其次，为项目调配资源可能是一个缓慢且痛苦的过程。经理向你提出需求，有一半的原因是为了绕过这一流程：这是一种避开常规渠道、快速且非正式的替代方案。如果你无法独自快速搞定解决方案，那就完全违背了初衷。

Does AI mean everyone can ship now? No. Shipping was never just writing the code³. It was about figuring out the shortest and most pragmatic path to the finish line (including figuring out what that finish line looks like, which is not trivial), solving all the little problems that crop up along the way, and ensuring that the relevant managers are happy and informed. LLMs can help with that process, but they cannot run it end-to-end. It requires too much context: about the specifics of the technical systems in your company, the people involved and their motivations, and so on.AI 是否意味着现在人人都能交付了？并不是。交付从来不仅仅是编写代码。它关乎找出通往终点线最简短、最务实的路径（包括弄清楚终点线是什么样子，这并非易事），解决沿途出现的所有小问题，并确保相关经理感到满意且信息同步。大语言模型（LLM）可以在此过程中提供帮助，但它们无法端到端地完成整个流程。这需要太多的背景知识：关于公司技术系统的具体细节、相关人员及其动机等等。

This post was inspired by Xiaoyu He’s Aggro is the Foundation, which is about mathematical research. I think there are many parallels to be drawn between the best writing about research (e.g. Richard Hamming’s classic You and Your Research) and software engineering, because software engineering is often a process of research. Software engineering research is aimed at a more trivial goal — how some specific program functions, or how it could be changed, instead of the broader questions of science and mathematics — but it’s research nonetheless. And if you can’t ship, you’re unlikely to be very good at it.这篇文章的灵感来源于 Xiaoyu He 的《快攻是基础》（Aggro is the Foundation），该文探讨的是数学研究。我认为关于研究的最佳论述（例如理查德·汉明的经典著作《你和你的研究》）与软件工程之间存在许多相似之处，因为软件工程往往就是一个研究过程。软件工程研究的目标更琐碎——比如某个特定程序是如何运行的，或者如何对其进行修改，而不是科学和数学中更宏大的课题——但它依然是研究。如果你无法交付，那么你很难在这方面做得出色。