principle-the-algorithm

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

The Algorithm

算法

Five steps, in order, for any change bigger than an edit you can see at a glance. The order is the principle. Each step is cheap only after the one before it, and the common failure is doing a late step on something an early step would have removed. Adapted from Elon Musk's five-step engineering process.

Make the requirements less dumb. Assume the requirement is wrong and make it less wrong. It comes from a person, not a department. "The ticket", "the linter", "the reviewer", or "the old code did it" is a source, not a reason; find the person and their reasoning. If you do not agree with the reasoning, do not accept the requirement, however smart the person who gave it, the human included. No is a valid outcome.
Delete the part or process step. Try hardest to delete the part, flag, layer, retry, or step entirely before touching step 3. Optimizing something that should not exist is the biggest mistake smart people make. If you never add anything back, you did not delete enough. Leaf: pstack
```
principle-subtract-before-you-add
```
.
Optimize what survived. Third step, not first. Have one part do many things instead of a parallel copy per caller. Look hardest at boundaries between owners and layers, where a wrapper wraps a wrapper. Leaves: pstack
```
principle-laziness-protocol
```
,
```
principle-minimize-reader-load
```
.
Accelerate. Be the part: walk one change through edit, build, check, and review yourself and note where you wait, crawl, or bounce. Tighten that. Leaf: pstack
```
principle-sequence-verifiable-units
```
.
Automate last, or you automate something that should not exist. Volume alone does not justify it; precision and reviewability do. pstack
```
principle-build-the-lever
```
still applies. It runs on what survived.

Run it again. This is not a one-time gate. Rerun it on the result before you ship; the second pass deletes more.

The tell. A citation of this principle names the requirement you made less dumb, who owned it, and what you deleted. A citation with neither means you skipped it.

对于任何不只是简单编辑的变更，都应按顺序执行以下五个步骤。顺序是核心原则。只有完成前一步后，后一步才足够低成本；最常见的错误，是在前一步本可移除的内容上执行较后步骤。改编自 Elon Musk 的五步工程流程。

让需求变得更合理。 先假设需求是错误的，再让它没那么错误。需求来自某个人，而不是某个部门。“ticket”、“linter”、“reviewer”或“旧代码就是这么做的”只是来源，不是理由；应找到提出者及其推理过程。如果你不同意其中的理由，就不要接受这项需求——无论提出者多么聪明，人类也不例外。拒绝也是有效结果。
删除某个部分或流程步骤。 在进入第 3 步之前，应尽最大努力彻底删除相关部分、flag、layer、retry 或步骤。优化一个本就不该存在的东西，是聪明人最容易犯的最大错误。如果之后从未加回任何东西，就说明还没有删够。叶子节点：pstack
```
principle-subtract-before-you-add
```
。
优化保留下来的内容。这是第三步，而不是第一步。让一个部分承担多项任务，而不是为每个 caller 创建一份并行副本。重点检查 owners 与 layers 之间的边界，尤其是 wrapper 包裹 wrapper 的位置。叶子节点：pstack
```
principle-laziness-protocol
```
、
```
principle-minimize-reader-load
```
。
加速。 亲自成为其中一环：带着一项变更走完编辑、构建、检查和评审流程，并记录在哪里需要等待、进展缓慢或反复跳转。针对这些环节进行优化。叶子节点：pstack
```
principle-sequence-verifiable-units
```
。
最后再自动化，否则你自动化的可能是本不该存在的东西。不能仅凭数量就进行自动化；精确性和可评审性才是理由。pstack
```
principle-build-the-lever
```
仍然适用。自动化应作用于保留下来的内容。

再次执行。 这不是一次性的关卡。发布前应对结果重新执行；第二轮会删除更多内容。

判断标准。 对这一原则的引用，应说明你让哪项需求变得更合理、该需求由谁负责，以及你删除了什么。如果引用中既未指出所质疑的需求，也未说明删除了什么，就说明你跳过了它。