为何我选择忽视聚光灯，作为一名资深工程师
Lalit Maganti
最近，我一直在阅读肖恩·格德克关于成为Staff+级别工程师的文章。他的作品（尤其是《聚光灯下的软件工程》和《这不是你的代码库》）言辞犀利，对任何在大科技公司工作的人来说都熟悉得令人刺痛。
从纸面上看，我符合他所描述的模式：我是谷歌的一名资深Staff工程师。然而，阅读他的作品却让我产生了一种挥之不去的不安感。起初，我将其归结为愤世嫉俗。但经过反思，我意识到问题不在于肖恩的写作，而在于我的阅读方式。
肖恩并非悲观；他准确地描述了如何在一个工程师被视为可替代资产、优先级按季度变化的世界里生存。但我的工作与之截然不同，而且我深知，如果我试图在那个环境中或以他描述的方式工作，几个月内就会精疲力竭。
相反，我选择了一条不同的道路，一条优化系统而非聚光灯、强调长期耕耘而非可替代性的道路。
我们生活在不同的世界
我们道路分歧的根本原因在于，肖恩和我运作于完全不同的世界，遵循着不同的法则。
根据肖恩的简历，我的理解是他主要在面向外部客户的产品团队工作。业务目标每季度都可能变化，成功由收入或月活跃用户数来衡量。在这种环境中，优化“聚光灯”是完全合理的。大科技规模的产品开发如同一个拥挤的房间：副总裁、产品经理和用户体验设计师都有强烈的意见。要取得成功，你必须灵活应变，并确保你的工作正是高管们当前关注的焦点。
另一方面，我的整个职业生涯更多地是在幕后：在开发者工具和基础设施团队中。
我的团队的客户是Android、Chrome乃至整个谷歌内部的数千名工程师。谷歌产品的最终用户甚至不知道我们的存在；我们的重点是确保开发者拥有收集产品和性能指标、使用详细追踪调试问题的工具。
在这种环境下，我们与领导层的关系非常不同。我们从来不是“每个人都想参与的热门项目”，所以高管们不会争相与我们合作。事实上，我的团队历来难以招聘产品经理。谷歌的产品经理职业阶梯激励的是引人注目的外部产品发布，因此我们无法为他们提供良好的“晋升素材”。此外，我们的反馈直接来自工程师。在中间增加一个产品经理会导致信息失真，拖慢原本紧凑、高带宽的反馈循环。
所有这些意味着我们的团队以“自下而上”的方式运作：不是高管告诉我们“你应该做X”，而是我们自己找出对客户最有影响力的事情，并致力于构建这些功能和工具。高管们则通过评估我们对更多面向产品团队的影响，来确保我们确实在解决这些问题。
长期耕耘的复利回报
在肖恩描述的产品环境中，目标每季度变化，功能通常是实验性的，速度是终极货币。你需要快速发布、迭代，并经常在市场变化前转移阵地。但在基础设施和开发者体验领域，背景知识才是货币。
将工程师视为可替代资产会摧毁背景知识。你可能会获得新的视角，但会失去关于系统如何实际出故障的隐性知识。长期耕耘一个系统，能解锁短期轮换无法实现的复利回报。
首先是模式匹配带来的效率。当你在一个领域停留数年，新的请求很少是真正“新”的。我不仅仅是在调试代码；我是在调试我的工具与数百个不同工程团队的交叉点。当一个新团队带着一个“独特”问题来找我时，我常常可以回顾过去：“我们在2021年与相机团队尝试过这种方法；这是它失败的确切原因，而这才是真正可行的架构。”
但更强大的回报是系统性创新。如果你每年轮换团队，你只能解决当前可见的严重bug。然而，有些问题只有在长期视野中才会显露其轮廓。
以我最近领导的项目Bigtrace为例；这个解决方案的出现，完全是因为我坚持了足够长的时间，才看清问题的全貌：
- 2023年初（观察）：我开始注意到一种模式。谷歌各团队收集了TB甚至PB级别的性能追踪数据，但他们难以处理这些数据。工程师们编写脆弱的、自定义的管道来解析数据，常常抱怨分析迭代过程缓慢且痛苦。
- 2023年大部分时间（研究）：我并没有急于构建生产系统。相反，在从事其他项目的同时，我花了大半年时间在后台悄悄进行原型设计。我收集了那些曾抱怨过的工程师的反馈，并且由于建立了长期关系，他们给了我诚实而深刻的反馈。我了解了他们对用户体验、延迟和吞吐量要求，并想出了如何满足这些要求。
- 2023年底至2024年初（执行）：我们构建并发布了Bigtrace，一个用于追踪数据的分布式大数据查询引擎。如今，它每月处理超过20亿条追踪数据，成为100多名工程师日常工作的关键部分。
如果我遵循“优化可替代性”的建议（即，如果我在2023年为了追逐新项目而转岗），Bigtrace就不会存在。
相反，我会在研究阶段离开，而我的继任者会看到工程师抱怨的相同“噪音”。但如果没有历史背景来识别缺失的拼图，我认为他们会很难构建出像Bigtrace这样的东西。
说“不”的力量
追逐“聚光灯”最诱人的论据之一是它保证了资源和行政层的关注。但这种关注是一把双刃剑。
高能见度的项目通常变化无常。它们伴随着高管反复无常的想法、政治操纵，并且常常陷入为了短期生存而牺牲长期质量的境地。对某些工程师来说，驾驭这种混乱是一种刺激。但对于我们这些关心系统稳定性的人来说，这感觉像是一个陷阱。
长期耕耘的优势在于它能产生另一种资本：信任。当你花费数年时间提供可靠的工具后，你就赢得了政治资本，可以在聚光灯威胁到产品时对它说“不”。
最近，聚光灯一直聚焦在AI上。每个团队都面临将其融入产品的压力。我们被反复询问：“你们为什么不将LLM集成到Perfetto中？”如果我在优化能见度，答案显而易见：构建一个LLM包装器，向领导层演示，并声称我们是“AI优先”。这对我的职业生涯来说将是一场轻松的胜利。
但作为系统的守护者，我知道Perfetto的核心价值之一是精确性。当内核开发者在调试竞态条件时，他们需要精确的时间戳，而不是幻觉。用户信任我们告诉他们“X是问题所在”，因为那确实是问题，他们不会在接下来的一周里徒劳地追逐一个不存在的问题去调试。
但重要的是不要走得太远：怀疑不应变成阻碍。对于AI，不是“永远说不”，而是“在能够正确完成之前，暂时不这样做”。
一个寻求聚光灯的工程师可能认为这种方法错失良机；我认为这是在保护我们产品之所以伟大的基石：用户信任。
影响力的替代货币
工程师们对离开“聚光灯”最常见的担忧是职业停滞。逻辑是这样的：如果我没有在谷歌I/O大会上发布炫酷的功能，而且我的工作不在我副总裁的前五名清单上，我怎么能晋升到Staff+级别？
确实，你失去了“行政层可见度”这种货币。但在基础设施领域，你获得了两种同样有价值、甚至可能更稳定的替代货币。
影子层级 在产品组织中，你通常需要给你的经理的经理留下深刻印象。在基础设施组织中，你需要给你的客户的经理留下深刻印象。
我称之为影子层级。你不需要你的副总裁理解你代码的复杂性。你需要其他关键组织中的Staff+工程师需要你的工具。
当Pixel部门的一位资深Staff工程师告诉他们的副总裁：“没有Perfetto，我们根本无法调试下一款Pixel手机”时，这句话分量极重。它沿着他们的汇报链向上传递，在总监/副总裁级别交叉，然后再传回给你的经理。
这种倡导之所以强大，是因为它是技术性的，而非政治性的。它很难伪造。当你成为一个关键系统的守护者时，你的晋升材料中充满了公司最受尊敬的工程师的证言：“这个人的工作促成了我们的成功。”
效用账本 当产品团队可能专注于日活跃用户或收入时，我们依赖跟踪工程健康状况的指标：
- 效用：每一个使用我们的工具修复的bug，都意味着一份工程师认为我们有用的记录。这是效用最纯粹的衡量标准。
- 关键性：如果Pixel团队使用Perfetto调试一个阻碍发布的卡顿问题，或者Chrome用它修复内存泄漏，我们的影响力就与他们的成功紧密相连。
- 普遍性：覆盖了相当大比例的工程师群体，证明你创建了一种技术“通用语”。当你看到公司里互不关联的部门使用共享的Perfetto追踪作为“人人都理解的参考”进行协作时，这一点尤其明显。
- 规模：摄取PB级数据或处理数十亿条追踪，比任何设计文档都能更好地证明架构的韧性。
当你将关键性（重要团队需要这个）与效用（bug正在被修复）结合起来时，你就创建了一个不受行政重组影响的晋升理由。
原型与自主性
Staff工程师原型 我远非第一个注意到“成为Staff软件工程师有多种方式”的人。威尔·拉尔森在他的书《Staff Engineer》中，将Staff+级别的工程师分为四种不同的原型。
肖恩描述的是问题解决者或得力助手：作为高管意志的执行者，介入紧急事务，一旦问题稳定就离开。而我描述的是架构师或技术负责人：角色由对特定领域的长期所有权和深厚的技术背景所定义。
对“运气”的反驳 我已经能听到批评声：“你只是运气好找到了你的团队。我们大多数人没有这种奢侈。”
我在本文中的所有建议有两个前提。首先，我迄今所采用的策略要求公司足够盈利以维持长期的基础设施投入。这条路径在初创公司或早期成长型公司中通常不存在；它适用于大科技公司。
其次，运气确实在找到一个好团队中扮演了角色。从外部准确评估团队和公司文化是非常困难的。但是，找到团队可能涉及运气，而在那里坚持近十年却是一个选择。
而且，至少根据我的经验，我的团队并不特别：我仅能在Android内部就说出其他五个类似的团队。当然，他们可能有总监或副总裁的变动，但核心使命和工程团队保持了稳定。
这些团队之所以显得罕见，并非因为它们不存在，而是因为它们常常被忽视。因为它们不能提供产品发布那种快速、可见的“胜利”，也不从事“炫酷的新功能”开发，所以它们面临的竞争更少。如果你的动力来自“向数十亿用户发布产品”或看到你的朋友和家人使用你构建的东西，你在这里不会找到满足感。这就是入场的代价。
但如果你想构建长期系统，并愿意用外部的认可来换取深度的技术所有权，你只需要拉开帷幕看看后面。
结论
科技行业喜欢告诉你“快速行动”。但还有另一条路。在这条路上，杠杆效应来自于深度、耐心，以及为他人奠基所带来的平静满足感。
你不需要追逐聚光灯，也能在大型公司中拥有有意义、高影响力的职业生涯。有时，你能做的最有野心的事就是保持不动，深入挖掘，并构建一些能持久的东西。与一个问题领域相处数年，直到你足够理解它，能够构建出一个Bigtrace。
注脚：
- 这里的“产品团队”并非指“前端团队”：即使是后端工程师，你仍然在直接服务于最终用户的某个环节工作。
- 这并非详尽无遗，Perfetto是开源的，我们也关心外部开发者，但这并非公司付钱给我们的原因。从公司的角度看，我们花在开源bug上的时间是“浪费”的，但我们这样做是因为我们相信开源使命。我在最近的一篇文章《论Perfetto、开源和公司优先级》中对此有更多讨论。
- 值得一提的是，LLM可能甚至不是“将AI融入Perfetto”的最佳解决方案：在我看来，“老派”的机器学习技术（如神经网络）有很多价值。许多追踪分析只是模式匹配。这是我希望在来年更多探索的方向！
- Android内核、Android系统健康、Android运行时、Android相机HAL、Android Bionic。