好书精读 · READ 920

《The Software Engineer's Guidebook》

格尔盖伊·奥罗斯 (Gergely Orosz) · 2023

EN →

一句话

这是一本把软件工程师这份职业整条路一次画完的书：从「代码能跑」的合格开发者，到独当一面的 senior，到带着一队人把事情做成的 tech lead，再到不管人却能撬动整个组织的 staff / principal——奥罗斯要讲清的是每一级产出的定义变了什么，以及一件多数人从没被明说过的事：你的报酬和成长速度，很大一部分不取决于你有多强，而取决于你身处哪一档市场、以及你的工作有没有被看见。

坐标

奥罗斯是匈牙利人，做过 Skype / 微软、Skyscanner，后来在 Uber 做工程师与工程经理（负责支付方向），离职后写起了《The Pragmatic Engineer》通讯，成了这个行业里读者最多的从业者视角写作者之一。这本书 2023 年自出版，没有出版社把关，也就没有出版社的删减——它是一份局内人的实地记录，不是一套理论。与已经精读过的两本 staff+ 名著相比，它的位置很清楚：拉尔森（Will Larson）的《Staff Engineer》讲的是「怎么拿到并定位这个角色」，赖利（Tanya Reilly）的《The Staff Engineer's Path》讲的是「到了之后每天具体怎么干」，而奥罗斯这本往前铺得更长、往外看得更宽：它从你还是个初级工程师开始讲起，并且额外附上了另两本都没有的一层——这个行业本身是怎么运转、怎么给人定价的。

核心论点

• 每一级不是「同一份工作做得更好」，而是产出的定义换了。初级看代码，senior 看问题是否被解决，tech lead 看团队的产出，staff+ 看组织的产出。用上一级的标准玩下一级的游戏，是绝大多数人卡住的真正原因。
• 「把事情做成」（getting things done）是被系统性低估的第一能力。不是最聪明的人升得快，是那些「交给他就一定会落地」的人升得快——因为在一个充满依赖、模糊和半成品的环境里，可靠地穿过最后那 20% 是稀缺品。
• 晋升是滞后指标，不是奖赏。公司不会因为你「值得」而升你，只会在你已经在做那一级的活、且这件事有人看得见、有人能替你背书之后，把标签补发给你。
• 同样的能力，在不同档次的公司里定价可以差出成倍。这不是道德问题，是市场结构问题；不知道这件事，你会把自己一个人的努力，拿去和一整套定价机制较劲。

核心概念，逐个讲透

三档市场：为什么同一个你，价格可以差好几倍

这是奥罗斯最有辨识度、也最容易被误用的一个框架。他观察到，软件工程师的薪酬不是一条平滑的曲线，而是几个分开的「峰」——因为不同公司根本不在同一个池子里竞争人才，定价逻辑各不相同。

示意 schematic：分档是定价机制的差别，不是「人的好坏」的差别；跨档的价差通常是成倍而非百分之几十。

这个框架真正的价值不在「教你跳槽」，而在于它把一件被个人化的事重新解释成了结构性的事。一个在第一档公司里干了六年、拿到过每一次「优秀」评级的人，常常会把自己的薪酬困境理解成「我不够强」——他会更拼命地写代码，而问题根本不在那里：他所在的公司的定价参照系里，压根就没有那个数字。就像一个在县城房产市场里努力提高房子品质的人，无论怎么装修，也换不到一线城市的挂牌价——不是他手艺不行，是市场不同。

但奥罗斯也没有把它写成一句「快去第三档」。他反复提醒的是另一半：档次越高，对「模糊问题里自己找方向」的要求也越高，容错越低，节奏越快；有人在第三档过得非常痛苦，也有人在第二档拿着足够好的收入和真正可控的生活。它改变你看问题的方式在于：从此你会把「我该更努力吗」这个问题，拆成「我该更努力吗 / 我该换个赛道吗 / 我该接受这个价位并去换别的东西吗」三个完全不同的问题。

公司类型决定了同一个 title 的含义

和分档并列的另一半是：同样叫 senior engineer，在早期创业公司、在快速扩张的 scaleup、在成熟大公司里，是三份不同的工作。创业公司要的是什么都能上手、能在没有流程的地方硬把东西做出来的人；scaleup 要的是能在系统开始撑不住时把地基重修、同时业务不能停的人；大公司要的是能在庞大既有系统与漫长协作链条里，把一件事推过许多张桌子的人。

由此得出一个非常实用的推论：换公司时真正的风险不是「我技术够不够」，而是「我上一份工作练出来的那套本事，在这里是不是还算本事」。一个在大公司里以「跨十个团队推动对齐」见长的人，进了八个人的创业公司会发现没有十个团队可推；一个在创业公司里以「三天上线」为荣的人，进了大公司会撞上评审、合规与迁移计划的墙，并把它误读成「这里的人都不做事」。奥罗斯的建议因此不是「选最好的公司」，而是「弄清楚这家公司此刻需要哪种人，再判断那是不是你想成为的人」。

「把事情做成」：最土的一条，也是最分水岭的一条

这本书里被反复擦亮的一个词是 getting things done。听上去像句正确的废话，但奥罗斯把它拆得很具体，拆完就不废话了：「做成」指的是从「我的那部分写完了」一路走到「用户在用、线上稳定、相关的人都知道它上线了」，中间所有没人认领的缝隙，全部由你去补。

缝隙具体长什么样：依赖的另一个团队没排期，你去找他们的负责人谈优先级；需求文档里有一句自相矛盾，你不是在群里抛个问题然后等三天，而是主动约十分钟把它敲定；测试环境没有数据，你自己造一份；上线后指标没人看，你建一个看板。这些事没有一件写在你的 JD 里，全部加起来却决定了「这件事到底有没有发生」。

为什么这条是分水岭？因为在任何一个稍具规模的组织里，难的从来不是写出那段逻辑，而是让一件跨越三个团队、两个季度、若干个模糊决策的事真的抵达终点。能做到这一点的人，在管理者眼里的价值不是线性高一点，而是完全另一类：他们可以被「托付」。它如何改变你看问题：你会停止用「我完成了分配给我的任务」来自我评价，改用一个更狠的问题——「如果我今天离开，这件事会不会烂在半路？」

产出的定义随级别改变：这才是「升级」的真身

这是全书的骨架，也是最值得记住的一张表。

每上一级，「我做了什么」的权重下降，「因为我，别人做成了什么」的权重上升。

关于 tech lead，奥罗斯强调了一个常被误解的点：它是一个角色（role），不是一个职级（level）。它可以轮换，可以某个项目里你当、下个项目里换人当；它不必然通向管理，也不比 senior 高一等。把 tech lead 当成「升职了」的人，往往会开始表现得像个小主管——争抢决策权、把最有意思的活留给自己；而把它当成「这段时间我负责让这支队伍跑起来」的人，会去做另一批事：把大块头拆成能并行的小块、提前发现两个人在做同一件事、把卡了三天的人捞出来。

影响力的三种半径：staff+ 到底在做什么

奥罗斯对 staff+ 的解释很克制，也因此很好用：staff+ 的价值不在于做更难的技术，而在于「选择」与「放大」。选择——在一堆都挺重要的事情里，判断哪件事做了会让接下来一年所有人都轻松，哪件事做了只是让某个季度好看；放大——同一份精力，用来自己写不如用来让二十个人写得对。

他把发挥作用的方式分成几个越来越难的层次：做（自己动手解决一个别人啃不动的问题）→ 教（让周围的人具备你这份能力）→ 定（把某个技术方向、某套标准、某个决策框架立起来，让以后所有人默认走在正确的路上）。第三层是效率最高、也最看不见的一层：一份写得好的技术方案文档、一次把「我们到底要不要自研」讨论清楚的会议，其影响会在此后两年里持续兑现，但它不会出现在任何人的代码提交记录里。这也解释了为什么 staff+ 特别需要「让工作可见」——不是为了表功，而是因为这个岗位上最有价值的产出，天然是最难被自动看见的那种。

晋升的真实机制：先做，再攒证据，最后才是申请

奥罗斯在这里写得相当不留情面，也是这本书最有实用价值的一段。公司的晋升不是「表彰过去的辛苦」，是「确认一个已经发生的事实」。评审委员会要看的是：这个人是否已经在按下一级的标准工作了，且有可核查的证据。所以正确的顺序是反过来的——不是「我干满三年了，该升了」，而是：

• 先跟你的 manager 把标准对齐：下一级在这家公司具体长什么样？请举两个例子。（各家的职级标准差异极大，跨公司的 title 几乎不可比——这也是他反复提醒不要拿 title 衡量自己的原因。）
• 选能产生证据的项目：一个技术上很有趣但没人关心的重构，和一个不那么性感却解掉了全组痛点的项目，在晋升材料里的分量完全不同。
• 持续记录：自己维护一份工作记录（很多人叫 brag document），随手记下做了什么、影响是什么、谁受益了。等到写晋升材料时才回忆半年前的事，你会漏掉大部分，而且拿不出数字。
• 找到会替你说话的人：评审桌上你不在场，替你说话的是别人。这不是钻营，是组织运作的物理事实。

它如何改变你看问题：你会不再把晋升当成一件「等公司来评判我」的事，而当成一件「我需要主动制造并呈现证据」的事。并且会接受一个不太舒服的现实——做得好，和被知道做得好，是两件必须分别去做的事。

意见与事实：一个小切口，却是资深与初级的真实分界

书里有一条看似小、其实极见功力的建议：说话时分清哪些是事实、哪些是你的意见，并且明确标出来。「这个查询在生产环境的 p99 是 800 毫秒」是事实；「我认为我们应该换成 Redis」是意见。初级工程师常把两者混在一起讲，于是讨论变成了立场之争；而把它们分开之后，讨论会自动落到该落的地方：先确认事实是否成立，再讨论从这个事实出发该怎么办。

这条之所以重要，是因为它同时解决了三个问题：它让你的判断可被检验（别人能指出你的事实错了，而不是觉得你人不行）；它让你更容易改变立场（承认「我的意见变了」远比承认「我错了」容易）；它让你在跨团队沟通里显得可信——可信不是因为你总是对，而是因为别人知道你不会把猜测说成结论。

往公司外面看：两种会复利的东西

奥罗斯本人就是这条建议的活样本——他今天的影响力不来自任何一家公司的职级，而来自持续对外写作累积起来的信誉。书里对此的主张有两层。

第一层是校准。只在一家公司里待久了，你会不自觉地把这家公司的标准当成行业的标准：这里认为难的事就是难的，这里的 senior 就是 senior。而公司内部的评价是一套封闭的坐标系，它可能整体偏了而没人告诉你。解法很朴素：定期看外面的职位描述、偶尔真的去面一面、和别家公司的同行聊具体做法。你不是为了跳槽，是为了知道自己现在站在哪。

第二层是职业网络与对外的痕迹。一起共事过、并且认可你的人，是你职业生涯里回报周期最长的一笔投资——多数好机会不是通过投简历来的，是通过某个记得你把事做成过的人来的。而公开写下来的东西（技术博客、开源、分享）则是另一种复利：它把「只有你前同事知道的你」变成「陌生人也能核实的你」。这两样都不能临时抱佛脚，只能在不需要它们的时候慢慢攒。

精华骨架

整本书其实在回答一个问题：一个软件工程师的职业生涯，究竟是被什么推动的？奥罗斯的答案由三块拼成，缺一块都会走偏。

第一块是能力的阶梯，而阶梯的每一级都在换定义。从「完成任务」到「解决问题」到「让团队产出」到「让组织走对方向」——同一个人越往上走，亲手写代码的比例越低，而「因为我，别的事情变好了」的比例越高。看不懂这次定义切换的人，会用更多的加班去解决一个根本不是工作量的问题。

第二块是被看见的机制。组织不是一个全知的观察者，它只能通过有限的信号来判断你：你写的文档、你主导的项目、你的 manager 转述的版本、别人在会上提到你的次数。所以「做好工作」与「让好工作进入组织的视野」是两件独立的事，而后者被无数工程师当成不体面而拒绝去做，代价则由自己承担。

第三块是你所处的市场。公司分档、公司类型、所处阶段，共同决定了你的努力会被换算成什么。这一块最反直觉，因为它意味着：在错的地方做对的事，回报可能远低于在对的地方做普通的事。

三块合起来就是这本书的完整主张：职业发展 = 能力的真实跃迁 × 让它被看见 × 处在一个会为它付钱的市场。三项相乘，任何一项接近零，结果都接近零——而绝大多数人只在第一项上用力。

常见误读与批评

误读一：把它读成一本「升职攻略」。书里确实有大量关于晋升、评级、跳槽的操作细节，但它的主张恰恰是：先真的会做那一级的事，其余才有意义。只学后半段的人，会得到一个很擅长写晋升材料、却撑不住那个位置的自己。

误读二：把「三档市场」当成「一定要去第三档」。分档描述的是定价机制的差别，不是人生排序。第三档意味着更陡的期待、更多的模糊性、更高的被裁风险和更大比例的股权（而股权可能归零）。这个框架的正确用法是知道自己在哪个游戏里、以及这个游戏的规则是什么，不是无条件往上爬。

最实在的批评一：这不是一本有证据的书，是一本有经验的书。它的结论来自作者在若干家欧洲与美国科技公司的亲身观察和大量从业者访谈，没有对照研究、没有数据集。这类知识有真实价值，但也天然带着幸存者偏差——那些照做却没成的人，不会出现在样本里。想要有实证支撑的工程效能讨论，得去看《Accelerate》那种路子的书。

最实在的批评二：它的许多建议隐含了一个宽松的就业市场。书成于科技业长达十年的扩张尾声，「不满意就换一家、换到第三档去」在那个语境里是可行的。到了普遍裁员、招聘冻结、晋升名额被砍的周期里，同样的建议可执行性会大幅下降；而「先做下一级的工作，再等公司确认」在一个已经宣布暂停晋升的组织里，可能只意味着你白干了一年。书里对这种周期性风险的处理是偏轻的。

批评三：结构性的门槛被低估了。「进入面向全球招聘的第三档公司」对不同护照、不同时区、不同母语的人，难度完全不同。签证、合规、时差、本地招聘政策这些硬约束，比个人能力更能决定一个人能不能跨档，而这一层书里着墨不多。

批评四：体量偏大，重复度不低。这是一本厚书（自出版、篇幅约七百页），覆盖面广是优点，代价是不少章节在别的书里已经被讲得更集中——tech lead 与管理那部分与富尼耶（Camille Fournier）《The Manager's Path》重叠，staff+ 那部分不如赖利《The Staff Engineer's Path》深。它的独特价值集中在两处：完整的阶梯地图，和那层别人不写的行业与定价常识。

十句话精华