最近一个在大厂坚持了14年的大哥，离开了自己的工作岗位去AI创业去了。作为一个优秀的程序员大哥在职期间贡献了大量的优秀代码，在离开时候大哥告诉我们，实际上在开发岗位上能高效的产出最重要不是你智商，也不是你的高超的coding技能，而是其他的。于是就有了本文总结，如何在大厂混成成功的工程师，注意本文纯干货，不涉及AI。

　　

　　大哥的经验总结起来，作为一个成功的工程师，需要处理好人际关系、政治斗争、目标一致性、以及各种不确定性。分享这些经验希望给新入职场的新人们参考，希望让大家可以避免一些弯路和陷阱。

用户导向

　　首先，最优秀的工程师都痴迷于解决用户问题。爱上一项技术并四处寻找应用场景固然诱人，每个开发工程师似乎都会痴迷这点。但真正创造最大价值的工程师却反其道而行之：他们专注于深入理解用户问题，并从中找出问题的解决方案。

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

　　工程师如果一开始就想着如何解决问题，往往会为了寻找理由而人为地增加复杂性。

统一目标

　　正确很容易，共同达成正确才是真正的挑战。即使你在技术上胜券在握，最终也可能输掉项目。在谷歌这样的大厂中不乏才华横溢的工程师，其身边到处都是极度聪明的人尖子。但是仔细观察一下，似乎他们都不会怎么开心，似乎充满怨气。这种怨气最终会以“莫名其妙的执行问题”和“莫名其妙的阻力”的形式爆发。

　　其实成功的关键不在于证明自己正确，而在于参与讨论以达成对问题的共识，为他人创造发言空间，并对自己确信的观点保持怀疑。

　　强烈的观点，但并不坚定——不是因为你缺乏信念，而是因为在不确定情况下做出的决定不应该与你的身份认同紧密相连。

行动为先

　　对完美的追求会让人裹足不前。大厂中不乏有工程师们花费数周时间争论他们从未实际构建过的产品的理想架构。完美的解决方案很少仅仅依靠思考就能产生——它往往源于与现实的接触，需要不断在实践中迭代打磨而成。

　　先动手做，再把它做好，最后再做得更好。把粗糙的原型展示给用户。写出设计文档的初稿。发布那个让你略感尴尬的最小可行产品（MVP）。一周的真实反馈比一个月的理论辩论更有价值。

　　势头带来清晰的思路。分析预想的崩溃没有什么实际价值。

清晰表达

　　清晰的表达能力是资历，聪明才智是成本。编写巧妙代码的本能几乎是所有工程师的通病。他们会以此来证明自己高超的Coding“技能”，就像武侠小说中的秘籍一样，让大家挖空心思去追求，让实际上作用并不大。

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

　　你的代码就像一份写给陌生人的策略备忘录，他们需要在凌晨两点系统宕机时维护它。优化时要考虑他们的理解能力，而不是你的代码是否优美。各个码届前辈高级工程师们的经验就是用清晰易懂来代替炫技。

合理创新

　　创新就像贷款，你需要通过停机、招聘和认知开销来偿还。对待技术选择，要像对待一个拥有少量“创新代币”预算的组织一样。每次采用非标准技术时，就使用一个代币。你负担不起太多。关键不在于“永远不要创新”，而在于“只在那些因创新而获得独特报酬的领域进行创新”。其他一切都应该回归平庸，因为平庸的失败模式是众所周知的。

　　“最适合这项工作的工具”往往是“在许多工作中都算不上最差的工具”。

人定胜码

　　你的代码不会为你代言，人会。很多工程师都错误的认为，只要我写出好的项目就会被人赏识，是金子总会发光的！但是实际上不是这样的。再好的代码也只会保存在代码仓库里，而你的经理会在会议上提到你，也可能不会。同事会推荐你参与某个项目，或者推荐其他人。在大厂中，决策往往是在你未被邀请参加的会议上做出的，依据的可能是没有认真撰写的总结，而决策者只有五分钟时间，却要处理十二项优先事项。如果没人能清晰地阐述你不在场时的影响，那么你的影响力实际上就变得可有可无了。

无码胜有

　　最好的代码就是你永远不必编写的代码。在工程师文化中，推崇重复造轮子。没有人会因为删除代码而获得晋升，即使删除代码往往比添加代码更能改进系统。你不写的每一行代码，都意味着你永远不必调试、维护或解释。

　　在动工之前，先仔细思考一下：“如果我们不做这件事会发生什么？” 有时答案是“没什么坏处”，那就是最佳解决方案。

　　问题不在于工程师不会编写代码或使用人工智能来编写代码，而在于我们太擅长编写代码，以至于忘记问自己是否应该这样做。

维护漏洞

　　规模扩大后，即使是你的漏洞也会有用户。用户数量足够多时，任何可观察到的行为都会变成依赖项——无论你做出过什么承诺。有人在抓取你的API数据，自动化你的异常行为，缓存你的bug。你不能把兼容性工作视为“维护”，而把新功能视为“真正的工作”。兼容性也是产品。

　　将弃用设计成迁移方案，并预留时间、使用合适的工具，同时考虑到用户的需求。大多数所谓的“API设计”实际上就是“API退役”。

调和团队

　　大多数“慢”的团队实际上是不协调的团队。项目进展缓慢时，人们的第一反应往往是责怪执行环节：员工不够努力、技术不成熟、工程师人手不足。但通常来说，这些都不是真正的问题所在。在大厂里，团队是并发执行的基本单位，但随着团队数量的增加，协调成本呈几何级数增长。大多数效率低下实际上源于目标不一致——人们在做错误的事情，或者以不兼容的方式做正确的事情。

　　资深工程师花在明确方向、接口和优先级上的时间比“更快地编写代码”的时间要多得多，因为真正的瓶颈就在这里。

专注任务

　　专注于你能控制的事情，忽略你无法把控的事情。在大厂里，有巨量的变化都超出我们的掌控：组织架构调整、管理决策、市场变化、产品转型等等。过度关注这些因素只会让你焦虑不安，却又无能为力。

　　那些保持理智和高效的工程师会专注于自身的影响范围。你无法控制组织重组是否会发生，但你可以控制工作质量、应对方式以及从中学习到的东西。面对不确定性，将问题分解成若干部分，并确定你可以采取的具体行动。这并非被动接受，而是策略性关注。把精力浪费在无法改变的事情上，就等于浪费了原本可以改变的事情的精力。

教会别人

　　写作能使表达更清晰。学习和提高某项技能最快的方法就是尝试去教别人。写作能带来清晰的表达。当向别人解释某个技术时，无论是在文档、演讲、代码审查评论中，甚至是与AI交流时，我们都会发现自己理解上的偏颇。将某些内容清晰地表达出来，让别人也能理解，这反过来也让自己更容易理解。

　　这不仅仅是慷慨分享知识的问题，更是一种利己的学习技巧。如果觉得自己理解了某个概念，试着用简单的语言解释它。理解有误的地方，恰恰是你理解不够透彻的地方。试图教会别人时就是在调试自己的思维模型。

变废为宝

　　往往哪些不被人所知的、使其他工作成为可能的工作是无价的。哪些粘合性工作，例如文档编写、新员工入职培训、跨团队协作和流程改进，这些都至关重要。如果你无意识地去做这些工作，它们会阻碍你的技术发展，并让你精疲力竭。误区在于把这些工作当作“帮忙”，而不是将其视为有意识的、有界限的、可视的影响。设定时间限制、轮换使用、将其转化为成果：文档、模板、自动化流程。并使其体现为影响，而非个人特质。

莫争是非

　　如果你赢得每一场辩论，你很可能是在积累无声的阻力。学会对自己过于自信的态度保持警惕。如果我“赢”得太容易，通常就说明出了问题。人们不再与你争论，不是因为你说服了他们，而是因为他们放弃了努力——他们会在实际行动中表达这种不满，而不是在会议上。

　　真正的目标一致需要更长时间。你必须真正理解其他人的观点，接受反馈，有时甚至需要公开改变想法。短期内觉得自己是对的，这种感觉远不如与志同道合的伙伴一起长期建设事物来得重要。

洞察目标

　　当一个指标成为目标时，它就停止了衡量。展示给管理层的每一个指标最终都会被操纵。这并非出于恶意，而是因为人类本性总是想对那些衡量的指标进行优化。如果你追踪代码行数，你会得到更多的代码行数。如果你追踪开发速度，你会得到过高的估算值。

　　高手的做法是：对每个指标请求都提供一对指标。一个用于衡量速度，一个用于衡量质量或风险。然后，坚持解读趋势，而不是盲目追求阈值。目标是洞察，而非监控。

承认无知

　　承认自己不知道的事情比假装自己知道更能带来安全感。对资深工程师来说“我不知道”并不是示弱，他们是在鼓励大家坦诚面对。当领导者承认自己的不确定性时，就等于在暗示其他人也可以这样做。反之，就会形成一种人人假装理解、问题被掩盖直到爆发的文化。

　　一些大厂的团队，资历最深的人从不承认自己的无知，这样的无知也造成的很多可怕的后果。没人提问，没人质疑既定假设。初级工程师保持沉默，因为他们觉得其他人都能理解。承认不足之处，才能有学习提高的基础。

积攒人脉

　　你的人脉关系比你拥有的任何一份工作都可以更长久。当需要向前迈进的时候，往往是人际关系打开了这扇门。新手们往往太专注于工作和任务，以至于忽略了人脉拓展。那些在公司内外都重视人脉关系的同事，在接下来的几十年里都受益匪浅。他们能最先了解机会，更快地建立人脉，获得职位推荐，并与多年来建立信任的人共同创办企业。一个人的工作不会永远持续下去，但你的人脉却会一直存在。保持好奇心和慷慨的态度去拓展人脉，与人交往时放弃功利主义的心态。

多做减法

　　大多数绩效的提升来自于减少工作量，而不是其他更优化的想法。当系统运行缓慢时，大家的第一反应是增加缓存层、并行处理和使用更智能的算法。一般来说这样是对的。但是优先需要问自己“我们运行了哪些不必要的东西？”，通过减少不必要的东西，往往能带来更多性能提升。做减法，删除不必要的工作几乎总是比更快地完成必要的工作更有成效。最快的代码是永远不会运行的代码。在进行优化之前，先问问自己这些代码是否应该存在。

流程记录

　　流程存在的目的是为了减少不确定性，而不是为了留下书面记录。最佳流程能使协调更便捷，降低失败成本。最糟糕的流程则是官僚作风，它的存在不是为了提供帮助，而是为了在事情出错时推卸责任。如果你无法解释某个流程如何降低风险或提高清晰度，那么它很可能只是增加了额外开销。

　　如果人们花在记录工作上的时间比做工作的时间还多，那就说明出了大问题。

简单重复

　　没有捷径，但有复利。专业技能源于刻意练习，稍微超越现有水平，反思，重复。年复一年，没有捷径可走。学习的进步在于创造新的选择，而不仅仅是积累新的知识。写作不是为了吸引眼球，而是为了清晰表达。构建可复用的基础模型。将过往的经验总结成行动指南。

　　如果工程师把职业生涯看作是复利投资，而不是彩票，那么他最终往往会取得更大的成就。

总结

　　以上提出了诸多的建议，密密麻麻，好像就是心灵鸡汤一样，但是实际上他们抽丝剥茧可以归结为几个核心理念：保持好奇心，保持谦逊，并记住工作始终与人有关，包括你的用户和你的团队成员。

　　工程领域的职业生涯漫长，足以让人犯下无数错误，最终依然能够取得成功。最让人敬佩的工程师并非那些事事都做得完美的人，而是那些从错误中吸取教训、分享发现、并坚持不懈的人。

　　对一个新手工程师，中段工程师，亦或是资深工程师，随着经历丰富，时间积累，你可以对这些内容越来越感到共鸣，恭喜你，你已经成长了。