优秀的工程师常常是正确的
原始链接: https://www.seangoedecke.com/being-right-a-lot
亚马逊有一条著名的领导力准则：“优秀的领导者常常是正确的（right, a lot）”。这条准则对领导者是否适用不好说，但对工程师来说绝对是真理：优秀的工程师常常是正确的。
Bryan Cantrill 在这里曾吐槽过亚马逊的这条准则。我同意他的观点，这条准则听起来有点傻，它也不是那种能指导艰难决策的根本原则（遇到难题怎么办？很简单，像优秀领导者那样选对的就行！）。但我认为这是一个不争的事实。优秀的领导者确实经常做出正确的判断。当然，这源于他们其他的特质：比如他们很聪明，或者善于招揽人才等等。我认为亚马逊这条准则的核心在于，综合评估上述特质太难了，不如直接问自己：“这个人是不是经常能做出正确的判断？”这样要简单得多。
好吧，虽然简单些，但也并非易事。你很容易看出一个领导者是否取得了成功（比如用户蜂拥而至、赚得盆满钵满、公司被视为神仙打工地点等）。但成功的原因有很多，有时候仅仅是因为在某个高杠杆的关键点上“虽然判断错误但运气好”。糟糕的领导者偶尔也会撞大运做出好产品。商业世界太混乱了，很难去准确评估。
但在工程领域就不同了。优秀的工程师常常是正确的。他们对软件系统运行方式的客观陈述是正确的（比如某接口的限流是多少）；他们制定的具体计划是正确的（比如这里不能加校验，但加在那边可以）；他们在写代码时做的无数个小决定也是正确的，这就体现在他们的代码通常能正常运行且 Bug 很少。
你可以通过很多方式评估一个工程师：聊天时听起来聪不聪明、用的是浅色主题的 VSCode 还是深色主题的 vim、头衔是什么等等。但如果你有时间观察，最可靠的评估标准依然是：他们是不是常常正确。对于技术同行来说，这种评估是潜意识的：当他们提出观点时，你是自然感到放心还是心存疑虑？审查他们的代码（PR）时，你会本能地带有多少挑剔的眼光？此外，你也可以留意他们满怀自信说出的话，最后是否被证明是正确的。如果你也是工程师，你的经理大概率正在默默观察这一点。
一点警告：有些工程师为了避免犯错，从不发表确定的技术观点。我认为这是失职。如果你是屋子里技术最好的人，提供信息和建议就是你的责任——这也是你的工作。总是说“好吧，我不确定”或给自己的话留足退路，会让非技术人员很难和你合作。无论如何，准则是“常常是正确的”，而不是“从不犯错”。如果你不勇敢表达，你就不可能常常正确。
继续这个话题，“常常正确”跟“永远正确”甚至“大部分时候正确”是有区别的。在技术极度不明确的领域（比如腐烂的老旧代码，或者前沿的技术难题），哪怕只有一部分时间是对的，也非常有价值。根据我的经验，犯错是可以原谅的，尤其是当你是唯一一个敢于站出来提供答案或计划的人时。
上面的内容并不能教工程师如何变得常常正确。那是一个复杂得多的话题1。但这是一个很好的自我绩效衡量标准：
- 你是否敢于站出来表达技术观点（无论是通过言语还是代码）？
- 这些观点常常是正确的吗？
注：这篇文章在 Hacker News 上引起了广泛讨论。
如果你喜欢这篇文章，考虑订阅我的邮件更新，或者[在 Hacker News 上分享它](news.ycombinator.com/submitlink?… engineers are right, a lot)。这里有一篇带相同标签的相关文章预览：
疯狂清理 JIRA 工单只是表面功夫，无法产生真正的价值
不要变成 JIRA 工单僵尸！我觉得很多有抱负的初级工程师都有过这种经历（我以前绝对干过）——对团队缓慢的进度感到沮丧，然后决定“不管了，我要把这些工单全搞定”。在很多团队里，完成比第二名多 2 到 3 倍的工单并不难。但这其实是条死胡同。你只会得到一句“干得不错，别累坏了”的口头表扬，却对晋升高级工程师毫无帮助。
继续阅读...
Footnotes
-
我对此只有一句话建议：在单一领域长时间地进行大量工作，以此建立深度的熟悉感。 ↩
