资深工程师不写代码时，究竟在干什么？

几个月前，一位我指导的开发者问了个让我愣住的问题："你一整天到底在忙什么？几乎看不到你提交代码。"他没有冒犯的意思，是真的困惑。他已经埋头写功能写了三年，以为通往资深工程师的路就是……继续这样。写更快的代码，解更难的题，提更多PR。

他不是个例。大多数中级工程师对资深工程师实际做什么，都有着危险的不完整认知。而这种误解，正是职业停滞的最大原因。

资深工程师不只是写代码。据我的经验，他们把50%-70%的时间花在永远不会出现在git记录里的活动上：系统设计、指导新人、管理技术债、跨职能领导。这些隐藏角色，把"有资深头衔的人"和"真正产生资深级影响力的人"区分开来。

以下是没人告诉你的那些事。

资深工程师不写代码时，到底在做什么？

资深工程师的工作不是产出最多代码，而是产出最大杠杆效应。曾任谷歌工程副总裁的Sarah Drasner将资深工程师描述为"力量放大器"——他们的架构决策和指导，能让5人团队产出10人团队的效率。

大多数人忽略的就是这种乘数效应。职业生涯早期，你的影响力大致与工时成正比：写代码，发布，完事。但这个模型在规模面前会崩解。资深工程师花一周设计正确的抽象，可能帮团队省下数月返工；花精力指导一个挣扎的新人，可能一个季度内就把他变成可靠贡献者。

我曾经对"他们只开会"的刻板印象翻白眼。直到我自己成了那种人。是的，资深工程师开会更多。但优秀的资深工程师用这些会议来塑造决策、消除模糊性、确保团队方向正确。会议本身就是工作。

正如Gergely Orosz在《The Pragmatic Engineer》中所写，资深工程师的核心角色之一是降低复杂度——把模糊混乱的业务问题，转化为简洁、可维护、可扩展的技术方案。这不是在代码编辑器里完成的，而是在对话中、在白板上、在设计文档里完成的。

隐藏角色一：系统设计师——比代码活得更久的决策

第一个隐藏角色是系统设计师。不是面试白板题那种。我指的是那些你的团队将与之共处数年的架构决策。

我曾交付过处理数千万请求的系统，最难的部分从来不是写代码。