从首席工程师身上学到的10条经验教训
向最优秀的人学习，成就最优秀的自己！
我仍然记得我与我们首席工程师的第一次一对一交流。我刚加入团队，急切地想要证明自己。我原以为会面临一场技术上的严苛考验，但相反，我们谈论了设计原则、业务影响，以及他称之为“工程成熟度”的东西。那次谈话彻底改变了我的思维方式。
在接下来的一年里，我跟着他参与棘手的项目，参加远超我职级水平的架构讨论，观察他在压力下如何工作。我从他身上学到的东西改变了我的编码方式、沟通方式以及做出贡献的方式。
以下是影响最大的10条经验教训。
每读完一条，请静静的回味 30s
1. 为接替你的工程师编写代码
“你的代码应该讲述一个故事，” 他说，“一个下一个人无需猜测情节就能读懂的故事。”
这让我深受触动。我不再写那些巧妙的单行代码，而是开始留下有意义的注释。我会把函数名写得更清晰，编写模块化的代码，这不仅仅是为了我自己，也是为了半年后调试代码的可怜家伙（那个可怜家伙可能是我自己…）。
2. 慢即稳。稳即快。
我过去常常匆忙进行部署，以速度为名敷衍了事。他向我展示了这种匆忙往往会导致错误，而这些错误日后会花费更多时间来解决。每做一个功能，都要打磨到位，不要留技术债。
相反，他处事冷静，即使在生产事故中也是如此。他会反复核实各种假设，提出更有质量的问题。有趣的是，他的方法实际上能更快地完成工作，而且返工更少。
3. 理解业务，而不仅仅是代码
“你可以打造出完美的功能，”他说，“但如果你不知道它为何重要，那依然没有抓住重点。”
他教我去问：
- 我们为谁打造这个功能、产品？
- 它解决了什么问题？
- 它是如何创造商业价值的？
这种心态帮助我更好地确定优先级，必要时予以拒绝，甚至提出更明智的解决方案。
4. 像读历史书一样阅读代码库
在一次代码审查中，我问道：“为什么要这样做？”他回答道：“你查看过git历史记录了吗？”
事实证明，我所质疑的奇怪模式是三次产品调整和一次客户升级的结果。不要认为代码很愚蠢——要想到其背后必有原因。
5. 永远不要说“只是”、“仅仅”、“就”
- “我们就快速添加一个API吧。”
- “我们就不能改一下架构吗？”
他在架构会议上禁止使用“仅仅”、“只是”、“就”这些词。它会过度简化问题，掩盖复杂性，并导致糟糕的规划。
现在，每当有人说“只是”的时候，我都会停下来问自己：真的有那么简单吗？
6. 选择合适的抽象，而非最抽象的抽象
他曾经把我那个优美、可复用、通用的类重构为三个简单且重复的函数。他说：“过早抽象比重复更糟糕。”
我了解到，优秀的架构并非不惜一切代价追求“不要重复自己”（DRY）原则，而是注重可读性、可维护性以及是否符合实际目的。
7. 学会向上、向下和横向沟通
看他向领导层做展示，堪称大师级教学。没有术语，权衡清晰，商业影响被置于首要和核心位置。
他会向不同群体表达不同内容：为工程师提供技术深度，为项目经理阐述高层次目标，让利益相关者安心。
沟通并非无关紧要的软技能，而是成为高级开发人员的核心要素。
8. 日志是你写给未来自己的情书
“写日志的时候，想象你在凌晨2点半睡半醒地试图调试生产环境中的崩溃问题，那时你希望看到什么样的日志？”
从那以后，我就痴迷于精心记录日志：
- 该系统试图做什么？
- 它接收了哪些输入？
- 哪里出了问题——原因是什么？
好的日志就像时光机。有时，它们比测试更能帮到你。
9. 知道何时该让问题（暂时）搁置
并非每个漏洞都需要立即修复。并非每个技术债务都值得专门花一个冲刺周期来解决。
他教我如何有效地进行分类处理——了解风险、评估影响并做出战略决策。
“工程学无关完美，”他说，“而是关乎判断力。”
10. 资历是由你对他人的助力程度来衡量的
最令人惊讶的领悟是什么？他的影响力不仅仅体现在他的代码上，还在于他如何让其他人变得更出色。
- 他指导他人时毫无私心。
- 慷慨地认可他人。
- 退一步，好让他人能进一步。
他告诉我：“你之所以成为一名更出色的开发者，不仅是因为你的代码有了改进，还因为你的团队取得了进步。”
结语
和他共事之后，我并没有成为一名首席工程师，但我的思维方式开始像首席工程师靠拢。这种转变影响了我此后参与的每一个项目。
这些经验教训并不总是让人好受，有些我是通过艰难的方式才学到的。但每一条都帮助我成长——不仅是作为一名开发者，还作为一名团队成员、领导者和思考者。
如果你有幸能与这样的人共事，那就留心观察。留意他们的行事方式。多倾听，少发言。并将从他们身上学到的东西传承下去。
好的工程师打造功能。更好的工程师培养人才。
enjoy ：）
原文：https://medium.com/the-pythonworld/10-lessons-i-learned-from-a-principal-engineer-that-made-me-a-better-developer-2d1337eb85b8
