这是一封写给每一位新入行软件工程师的信，关于那些我在职业生涯头十年里没人告诉我的事。不是泛泛的忠告——是真正会产生复利的具体习惯，背后有15年交付经历为证。如果我能回到过去，把这份东西递给那个刚在安曼 HAKEEM 国家电子病历项目入职的22岁自己，我一定会的。
第一条：先读代码，再写代码
头十年里杠杆最高的单一习惯，是在生产代码库里有意识地阅读别人写的代码。不是略读——是真正在读，逐文件、逐函数，在每个分支处问”这东西为什么在这里”。
我尊敬的每个高级工程师都有这个习惯的某个版本。听起来很显然。也是初级工程师最先跳过的事，因为读代码感觉没写代码高效。但它其实更高效。没有大量阅读就直接写，会让你重新发明代码库里已有的函数，发明与既有抽象相冲突的新抽象，提出违反原作者已在代码结构里编码的约束的设计。
在任何新代码库入职的第一个月，留出整整一周专门阅读代码，什么都不干。你的经理会觉得你没在产出。三个月后，你的产出会远远好于那些跳过这步的同级。复利效应。
第二条：把你学到的写下来
每个代码库都有没有文档记录的不变量。每个团队都有活在三个人脑子里的潜规则。每个生产系统都有在事故中学到的奇特边缘案例。
随手记下来。 不是记在私人文件里——是记在共享知识库里（仓库的 docs、团队 wiki、具体模块的 README）。写的过程会逼你把学到的东西说清楚，这会暴露你其实没真正理解的地方。同时也意味着下一个人可以跳过你刚花掉的那一周。
说句有点自我的话：靠写文档积累的”有帮助的工程师”声誉，比靠交付积累的来得更快。又交付又写文档，你在建一段职业生涯；只交付不写文档，你只是在消化工单。
第三条：卡一个小时，就问人
卡了一个小时，就去问。不是三个小时。是一个小时。
每个高级工程师都经历过：盯着屏幕半天，毫无进展，然后别人用30秒回答了你的问题。那半天白费了。通过一个精准的提问本可以学到的东西，你一点没学到。你在那半天里也没产出任何东西，也就是说团队为你的沉默买单了。
反驳意见是”我想先多努力一下”。这个本能是对的，但校准通常是错的。一个小时。然后问。如果你觉得难以启齿，还是问。那点难堪是一笔声誉税，远比”初级工程师一次消失半天”这笔税小得多。
第四条：调试时，旁白
调试什么棘手的东西时，大声说出你在想什么（或者写在终端临时文件里，或者在 Slack 的草稿频道里）。“我觉得 X 是因为 Y 发生的。如果这是真的，Z 应该可以观察到。让我检查一下 Z。嗯，Z 没有观察到。所以 X 不是因为 Y。还有什么会导致 X？”
这不是为了表演。是避免在原地打转的方法。旁白版本的调试会暴露你本来会悄悄做的假设。它还有个副作用：把你的调试过程变成一个可以讲给别人听的事后故事，这对团队的价值巨大。
第五条：一个测试比它能捕获的 bug 更便宜
我指导过的每个初级工程师，头一年都有同样的诱惑：跳过测试，“因为我确定这能跑通”。说实话：你永远不确定。没人是确定的。测试是它能跑通的证据。没有测试，“能跑通”只是一种感觉，而感觉在下一个工程师编辑那个函数时活不下去。
写测试。尤其是边缘案例。尤其是那些”显然能跑通”的枯燥的 happy path。你跳过的测试，就是捕获你上线的 bug 的测试。
第六条：主动去做那些不性感的活
每个团队都有没人想接的工作：修一个不稳定的测试、给一个让人困惑的模块写文档、重写一个脆弱的脚本、维护 on-call 交接模板。主动请缨。
三个理由：
- 你用功能开发教不了你的方式深入了解了系统。
- 你积累了特定的高级工程师声誉：一个在减熵的人。这比任何单个功能都值钱。
- 高级工程师稀缺。每个团队都需要他们。建立可见的证据证明你就是那个人，是被当成那个人对待的最快路径。
第七条：你的第一个经理是数据点，不是校准
如果你的第一个经理很好，珍惜他们——同时认识到他们是异常值。如果你的第一个经理不好，这不代表经理这个群体就是这样。我认识的大多数高级工程师都经历过完整的谱系。
实际意义：不要基于你第一个经理对你的看法做长期职业决策。那个看法是一个人的视角，而且那个人自己大概也没受过管理者培训。
另外：当你的第一个经理给你听起来不对的建议时，问”哪里不对？“而不是直接否掉或全盘接受。大多数第一任经理的建议是某个真正有用的东西经过扭曲之后的版本。和他们一起拆解它。他们往往也能从这个拆解过程中学到东西。
第八条：开源作品集是职业发展的作弊码
我认识的每个最终做到自己热爱的工作的工程师，都有可见的作品库。不一定是热门项目——是可见的。几个 OSS 贡献、一个他们写下来并做了文档的小工具、一系列博客文章、一个会议演讲。某种东西让招聘经理 Google 他们时，能看到一幅连贯的画面：“这就是这位工程师思维方式的形状。”
没有这些你也可以是一个优秀的工程师。你会得到更少的机会。在每个阶段，有作品集都比没有更便宜。现在就开始。不需要搞得很大。上线一个小工具。写三篇文章。给你在用的东西做个贡献。
当下的我发布这个你正在阅读的网站，部分就是对这个建议的重新承诺。我有几年懈怠了。我在纠正这件事。
第九条：会复利的技能是清晰
不是聪明。不是速度。不是深度。是清晰。
一句话解释一个决策的能力。写出说明”为什么”的 commit message 的能力。让下一个工程师知道发生了什么的代码库的能力。告诉 PM 功能需要三周而不是六周、并且清楚展示为什么的能力。
其他的你都会在路上学到。清晰会复利，早早建立它的工程师拥有不断累积的优势。
第十条（安静的那条）：对自己的兴奋保持怀疑
我见过的——也亲身犯过的——最昂贵的错误，都来自于在问题被真正理解之前就对某个解决方案感到兴奋。“我们来重写这个。""我们用这个新框架。""我们拆成服务。“兴奋是个信号，但不是决策函数。当你注意到自己对某个技术选择感到兴奋时，等一周。把计划写下来。睡一觉。找一个比你冷静的人来挑刺。
如果兴奋在一周后还在，那它是真实的。
如果没有，你省了自己几个月。
就这些。就是这封信。它不完整，但它诚实，是我希望有人在我22岁时递给我的东西。如果你正在开始第一份工作，有人把你引导到这里，我很高兴，也希望其中一些能帮你节省时间。