大约 年前，当我加入 Google 时我以为这份工作的主要就是编写优秀的代码。我在部分情况下是对的，

但因为待的时间越长，我越发意识到，那些真正发展很快的工程师。并不一定是编程技术最强的人——而是那些懂得如何驾驭代码之外一切因素的人：人际关系、政治博弈、目标对齐、还有各种不确定性。

这些是我希望自己能早点知道的经验教训。其中一些如果早点知道，可以帮我少走几个月的弯路；老实说，另一些则花了我数年时间才彻底参透。

这些经验无关具体的技术——技术更迭太快，根本无关紧要。它们关注的是那些反复出现的模式，无论项目还是团队，都如出一辙。

我分享这些经验，是因为我曾受益于其他工程师的帮助。这就当是我的一次回馈吧，老实说，

. 最优秀的工程师都痴迷于解决使用者问题

爱上一项技术并到处寻找使用场景。这很有诱惑力，我也曾如此，每个人都曾如此。按理说，但真正创造最大价值的工程师却反其道而行之他们专注于使用者问题。并让方法从这种理解中自只是然地涌现。

以使用者为中心代表着花时间处理支持工单，与使用者沟通。观察使用者遇到的困难，不断追问“为什么”，直到找到问题的症结所在。说起来，真正理解问题的工程师往往会发现，方案比任何人预想的都要简单。

从方法出发的工程师，往往是为了给方案找理由而制造复杂性。

. 证明你是对的很容易。“一起达成共识”才是真本事

即使你在技术上胜券在握，最终也可能输掉项目。我曾亲眼目睹一些才华横溢的工程师。 因为总是自诩为房间里最聪明的人，而默默地积攒怨气。

这种怨气最终会在后期以“莫名其妙的执行问题”和“莫名其妙的阻力”的形式显现出来。

关键不在于证明自己正确。而在于进入讨论，在问题上达成一致，给他人留出空间，并对自己确信的观点保持怀疑。老实说，

观点鲜明。但心态开放——这不是因为你缺乏信念，而是因为在不确定性下做出的决策不应与个人身份绑定。

. 行动至上。先发布

你可以修改一个糟糕的页面但无法修改空白页

对完美的追求会让人裹足不前. 我曾亲眼目睹工程师们花费数周时间争论他们从未实际建立过 的产品 的理想架构。

完美 的方法很少仅仅依靠思考就能产生——它往往源于与现实 的碰撞。AI 在这方面能提供很多帮助.

先动手做。再把它做好，最终再做得更好。把粗糙 的原型展示给使用者。写出设计文档 的初稿，发布那个让你略感尴尬 的最小可行产品。

从一周 的真实反馈中学到 的东西，比一个月 的理论辩论 要多得多.

只有行动起来方向 才会清晰；陷 在分析里什么都做不成.

. 清晰是资深，炫技是负担

写出“整洁”代码 的本能 在工程师中几乎 是普遍存在 的。这感觉像 是能力证明.

但软件工程 的本质 在于投入时间和精力，并与其他程序员 协作。在这种环境 下清晰性 并非风格偏好，而 是降低运维风险 根本所在.

Your code 就像 一份 写给陌生人的策略备忘录，他们 会 在凌晨 两点 程序宕机 时维护 它 ..

. 创新就像贷款。你需要通过停机、招聘和认知开销来偿还

Here you may want to reformat your content in a 娱乐ter way...