高阶工程师必须写代码
大家好，我是Tony Bai。
“如果你不写代码，你就不是一个软件工程师。”
这句话出自前 Uber 杰出工程师 (Distinguished Engineer) Joakim Recht 之口。在他看来，无论你的级别有多高，哪怕到了 Principal 或 Distinguished 级别，只要头衔里还有“工程师”这三个字，你就必须保持手感，持续编码。
近日，Joakim 接受了一次深度访谈，回顾了他在 Uber 从一名普通高级工程师一路成长为杰出工程师的完整历程。他不但分享了那个让他获得关键晋升的“史诗级”项目，还坦诚地谈论了办公室政治、不公平的晋升制度、以及他对“影响力”的独特理解。
这既是一个成功者的故事，也是一份关于如何在大型科技公司中保持清醒、持续成长并最终实现自我价值的深度指南。
晋升的秘密 —— 影响力不是“求”来的，是“做”出来的
Joakim 的晋升之路，始于一个朴素的愿望：懒惰。
起初，他只是负责管理一个名为 Schemaless 的数据存储系统。每次由于硬件故障需要替换主节点时，都需要手动操作 Puppet，繁琐且易错。
“我真的不喜欢重复做同样的事情。” Joakim 说。于是，他和团队开始尝试将数据库容器化，通过 Docker 来自动化管理这些操作。
这个最初只为了解决“自己团队痛点”的小项目，最终演变成了一个庞大的内部平台（Odin），接管了 Uber 几乎所有的有状态负载。在他离开时，这个平台管理着 12 万台物理服务器和 50 万个数据库实例，而核心维护团队只有 20 人。
给我们的启示：
Joakim 并没有在一开始就画一个“我要掌管全公司数据库”的大饼。他的影响力扩张遵循了一个自然的路径：
解决自己的痛点：自动化自己团队的重复劳动。
解决邻居的痛点：把工具推广给旁边的团队。
解决公司的痛点：逐步扩展到更广泛的组织，最终成为全公司的基础设施。
真正的晋升，是对你影响力范围 的自然确认，而不是因为你填写了一份完美的晋升文档。
关于“写代码”的执念 —— 拒绝成为“白板架构师”
在许多大厂，晋升往往意味着“远离代码”，转向文档、会议和 PPT。但 Joakim 对此坚决说 不。
“如果你停止写代码，你就会失去对系统的感知。你或许能画出高层的架构图，但那些设计往往会脱离现实。当你把设计扔给别人实现时，他们会想：‘这是哪个不懂装懂的家伙画的？’”
他认为，保持 Hands-on (亲力亲为) 有两个巨大的好处：
保持信任：如果团队成员知道你不仅懂业务，还能写出高质量的代码，甚至愿意干“脏活累活”，他们会更愿意听取你的建议。
保持敏锐：只有在代码一线，你才能第一时间感知到系统的腐坏和痛点，从而做出正确的架构决策。
对于那些只想做“高大上”设计，把“简单工作”丢给下属的高级工程师，Joakim 建议反其道而行之：把困难的、有趣的工作委派给团队成员，让他们成长；你自己去承担那些枯燥的、修修补补的“脏活”。 这不仅能赢得尊重，还能让你从微小处发现系统性的改进空间。
面对“不公平”的晋升 —— 心态决定一切
Joakim 并不避讳谈论大公司的阴暗面。他回忆起早期的 Uber 晋升委员会，那就是一场“没有任何数据支持的、纯粹靠经理口才”的辩论赛。
“这完全取决于你的经理有多擅长推销你。如果你有一个糟糕的经理，你就完蛋了。”
即使在制度完善后，绝对的公平依然不存在。项目被砍、依赖方掉链子、甚至仅仅是因为团队整体表现不佳，都可能成为你晋升路上的绊脚石。
他的建议：
不要成为“晋升驱动开发” (Promotion Driven Development) 的奴隶。专注于提供价值。
“只要你持续地解决问题、消除浪费、帮助他人，晋升通常会随之而来。如果你整天焦虑于‘如何找到一个能让我晋升的项目’，你反而可能动作变形，最终一无所获。”
影响力的最高境界 —— “盗梦空间”
当被问及如何有效地影响他人时，Joakim 分享了一个类似《盗梦空间》的技巧：最好的结果，是让对方觉得那是他们自己的主意。
不要试图用权威压人，也不要指望每个人都能立刻被你的逻辑说服。有时候，你只需要在对话中种下一颗种子。
“也许几个月后，你会听到他们在讨论你的想法，甚至充满激情地捍卫它，仿佛那是他们自己想出来的。那一刻，你就赢了。不要去争夺功劳，要享受这种‘想法生根发芽’的成就感。”
小结：给年轻自己的建议
在访谈的最后，Joakim 给年轻的自己（以及所有年轻工程师）提了一条建议：保持好奇，不要被吓倒。
“那些看起来很厉害的人，其实也是普通人。他们可能只是比你多了一些经验，或者更擅长包装自己。不要因为觉得某件事‘太难’或‘太高端’就不敢去尝试。计算机科学不是火箭科学（虽然有些也是），它只是计算机而已。保持好奇心，去尝试，去犯错，这是成长的唯一捷径。”
资料链接：https://www.youtube.com/watch?v=feNh_ubBAMI
你的看法是什么？
Joakim 的观点非常犀利，尤其是关于“级别越高越要写代码”的论断。结合你所在的团队或公司，你认同这个观点吗？在你身边，那些高T/P的架构师们，还在坚持写代码吗？如果不写，他们是如何保持对系统的敏锐度的？
欢迎在评论区分享你的观察和思考！ 让我们一起探讨工程师的终极成长之路。👇
如果这篇文章给你带来了新的职业启发，别忘了点个【赞】和【在看】，并分享给身边正在为晋升或成长感到困惑的朋友！
如果本文对你有所帮助，请帮忙点赞、推荐和转发
！
点击下面标题，阅读更多干货！
- 除了技术能力，什么决定了软件工程师的上限？答案是“品味”
- 从“键盘牛仔”到“规范工程师”，AI浪潮下的程序员身份危机
- 重构还是重写？GitHub工程师维护Go大项目的实践指南
- 写出让同事赞不绝口的Go代码：Reddit工程师总结的10条地道Go编程法则
- AI 时代的初级工程师生存指南：别让“万能”的AI工具，毁掉你最宝贵的成长期
- Twitch工程师的Go进阶之路：为何你写的Go代码，总感觉“不对劲”？
- 从0到1.5亿QPS：Uber核心存储架构的十年演进与缓存设计哲学
🔥 还在为“复制粘贴喂AI”而烦恼？我的新极客时间专栏 《AI原生开发工作流实战》 将带你：
告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码👇，开启你的AI原生开发之旅。
扫一扫
6万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
