2018/10

大多数东西大家都已经谈过了， 这里稍微聊聊几件事情。 以下纯属个人观点， 不代表亚马逊或亚马逊的立场。

我其实本来是想一直留在学校读书， 然后以后教书的。 来西雅图的亚马逊纯属偶然。

这些年在亚马逊做开发， 感受最深刻的就是学到了很多东西。 回头看刚入职的时候， 当时还真是很多事情都不懂。 所以现在也不敢说自己懂什么。毕竟过个几年再看， 现在还是什么都不懂。 我开始有时候还会以为自己是个工程师、以为做SDE的真的是做software development engineering。

这不是说所有的刚入职的应届生跟我当时一样什么都不懂。 今年遇到一个本科实习生， 对于开发和管理上的见解非常深入， 不比某些SDE III弱。 不知道他怎么领悟的。

最开始工作时我喜欢做些operations方面的苦活。因为当时觉得在西雅图10来万年薪已经很高了。组里大家不想干的活我就多做点才对得起这工资。当时组里同事对这个做法经常表示不解…因为一般当时最好的项目开发的活一般都是给实习生和SDE I做的。 这样可以让这些新人多写code， 在做code review的时候就可以更方便培养他们的设计灵感。 当然这些我当时都不懂。 我当时看我们SDE III一直在干一些又累又没人欣赏的脏活累活， 所以我也干。

那个组做的系统当时并不容易理解。 问题也多。我入组之前据说每晚得手动重启才不会把内存跑没。但是我反正新手， 也不知道问题所在。 我还以为干这行就是这样。

后来做了一年多之后组里做了几次系统重构。 新版本比老版本好懂多了， 也稳定多了， 我才开始感受到什么叫“好系统”。

之后大概有一两年， 做了不少系统设计， 学了很多销售领域相关的知识， 但是并没有抓到要领。 当时也没意识到系统设计最重要的就是要好懂。 那时候做设计主要靠灵感。等到换了组， 遇到了更难懂的系统、更大的设计问题， 才慢慢开始通过读书和找专家咨询来更正式地学习开发和管理。 学习初期犯了很多设计、领导方面的错误。 也没人跟我追究。 这些错误对公司和组造成的伤害我到现在才明白。 但是也没人跟我提过。 有次我跟经理提到这些问题， 经理跟我说：“没有人是通过一直做出正确的选择来学习的。”

这些年也遇到过几个比较普通的经理（虽然我也很喜欢他们， 但是当时不知道好经理是什么）， 当时对薪水和职位就看得比较重。 现在遇到了很好的经理， 可以从他那里学到很多开发、管理、以及销售领域相关的知识。 对于薪水和职位就反而看得没那么重了。

即使是很普通的经理， 也都很关注我的成长。 有的给我找mentor， 还有的带我去跟客户和领域方面的专家接触、学习， 带着我建立我自己的职业网络。

我也遇到过两个很差的经理。 一般这种经理都不会很关心手下员工的成长（也有的是没时间管）。 一般这种经理都不会在一个组留太久。 大概几个月到一年半就会被转走。

亚马逊里只要你知道怎么操作， 很多事情可以大胆去做。 其实级别越低，话语权越高。 因为级别低的就算说错了、做错了也是理所当然。 所以想说什么、想做什么， 只要目的是好的， 都可以大胆去尝试。 当然了， 别违法。

接下来谈一下几件大家可能会比较关心的事情。

1. 关于是否应该来亚马逊

如果你不是太缺钱（比如学生债很重之类的）， 亚马逊西雅图总部是一个适合职业成长的地方。今年（2018）亚马逊的应届生起薪不比别的类似公司低， 所以如果负债太重， 这类公司可能都不适合你。

不管你是什么专业， 都可以从这里的SDE I做起。 现在亚马逊招的本科生中， 有很多理科非电脑专业的。 我也见过很多文科、医科的， 读个半年的电脑硕士就来亚马逊当SDE实习生的。

个人而言非常喜欢这样的员工。 他们的思维模式往往非常灵活， 可以给公司带来不同的视角。 如果你背景就是电脑， 也很好。 这样上手快， 也就有时间多学一些别的专业的东西。

传统上，亚马逊大多数组会给新SDE I甚至实习生从头到尾的”ownership” （近三年某些部门有一些变化， 之后会提到）。 很多新人会去与客户谈项目、设计系统。一直到最后的购买硬件、发布功能、系统， 都可能是新人在主导的。这个ownership不应该被曲解为加班加点赶活。 只是说这个实习生或者SDE I拥有整个项目最高的话语权。

比如我今年就看到一个组的实习生， 在花了几周与他的客户讨论和深入分析之后， 成功说服他的组员去放弃他的实习生项目。 他的经理之后又花时间跟他一起开始了一个完全不同的项目。 这种自主能力是亚马逊强调的ownership。

这里同时要注意， 自主和自私是不同的！有人来帮着做项目是好事。 如何有效利用他人的帮助， 也是自主能力的一部分。

这种待遇在别的公司会比较少。这也是为什么有工作经验之后， 想面试进亚马逊难度反而会很高。一般工作经验3-5年的人， 面试亚马逊SDE II失败率很高。 因为这个阶段的普通程序员是很少会做项目规划和系统设计的。然而亚马逊的员工有很多从实习生就在做这些。

反之也同理。 我听说过不少起亚马逊SDE II跳槽到微软当Principal Engineer的事情。

当然并不是所有组都是这么好。 这点之后会详细讨论。

2. 关于亚马逊中国

亚马逊中国的开发，现在的确不够自主。 以前其实亚马逊印度也是全部都得听西雅图的命令。 一方面是因为不是总部， 另一方面是印度文化上比较随和。后来有一年派去印度一个Principal Engineer， 带领一群人建立这方面的思想， 最后改变了印度一些部门的文化。 虽然有些部门还是老样， 但是很多印度部门已经自主化， 完全可以和西雅图这边的想法抗衡。个人希望这种文化也可以传播到中国。

3. 关于oncall

个人而言很喜欢oncall。 oncall是学习机会。 软件行业里大多工作都是在已有的老系统基础上开发的。oncall可以让我们学习到老系统在开发和成长过程中所犯的错误， 进而在自己做开发时能够有更好的质量和效率。

对于做新功能开发的人而言， 不去了解自己写的程序长期的隐患， 就是失去了能够让自己进化的学习机会。

工作中有时能遇到只喜欢开发新东西的员工。 我对这种倾向不鼓励。 但是亚马逊里的确也有组是专门这样做， 做完了程序给别的组做operations (oncall)。 因为没有后顾之忧， 这样的程序很难保证质量。

如果一个新人加入了一个比较好的组， 这个新人很可能经常对于自己前一个月写的程序悔恨不已。 组里会给新人犯错的机会。 而犯的错通常会在oncall时被发现。

4. 关于组与组之间的差异

当时我入职的时候， 有人专门讲过这件事情：亚马逊的组的规划是以达尔文主义为中心的。 所以每个组都是自主的个体， 任意发展。 发展得好的就可以发扬光大， 发展得不好的就会被重组。

这是组和组之间体验不同的最大原因。

这个原因导致一个组好不好， 和它的经理、系统、开发者， 有直接关系。 很多人对于Software Development Manager (SDM)的理解有误区， 以为就是看大家效率、监视一下项目进度、然后有时候给人升个职、有时候给人来个PIP…换句话说以为SDM只是个管人事、管项目日程的。这个误解来源于很多人对于项目“成功”的定义的误解：

亚马逊项目的成功的定义不仅仅是“解决了问题”， 更是“培养了人才”。

也就是说亚马逊SDM的核心任务是培养SDE。好的SDM其实是很少的。 因为好的SDM必须有能力从各方面去培养手下的SDE。 如果一个SDM手下有个SDE III， 这个SDM的能力至少得接近于Principal Engineer才能够有效培养他。

我已经有几年没遇到特别好的SDM了，直到最近才又遇到特别好的SDM。 这几年遇到过很多比较普通的SDM。 大致上普通SDM分两种：

一种往往只有管理经验， 却对软件开发的各种流程、系统设计、以及其工作的商业领域并不是特别了解。这样容易给组里带来一些非最优的项目和解决途径。而且很难领会到怎么有效管理SDE – 因为不懂什么样的开发流程适合他现有的处境。 这处境包括小组的商务、包括组员的能力、包括与外组的关系等等。更糟糕的就是这样的SDM往往不懂得如何辅导他的SDE。

另一种虽然是SDE的背景， 但是缺乏管理经验， 经常挡在员工道上。比如有的会micromanage他最能自主的员工、却忘记管那些不能自主的员工。

这两种SDM都可以通过学习来进步。

所以如果在亚马逊工作， 并对自己的组经理不满意， 可以多了解了解别的组的一些做法， 用以改进自己的组、辅助自己的经理的进步。

一般没有人会阻止我们去做这些。 当然了， 我们也需要有足够的工具去理解现有问题和实行改变。

做这些改变的过程， 也是我们学习的机会。具体的工具有很多。 比如《Peopleware》就是一本这方面很不错的教材。

这里稍微提下PM的问题。 有些朋友提到被PM赶活。 这是近三年在有些部门开始有的问题。 我所了解的一些组以前PM很少。 这些年PM开始多了一些。 一个好的组会知道自己什么时候需要PM， 什么时候需要cross-functional的SDE。 并根据情况在这之间转换。 通常一个组需要有大量合作时， 会需要一个PM。 而好的PM应该促进SDE与客户的交流， 而不能总是直接自己去交流了， 然后给SDE丢requirements。 SDE不理解客户具体的问题会导致解决方案难以适应未来的需求。 主要的原因是SDE是最后做软件模型的人。 如果SDE理解客户的具体问题， 就更能预测长期的需求， 进而会做出更合适的模型。 所以所谓的系统设计， 设计的是所从事的领域的模型。 对一个领域越了解， 系统就可以设计越能适应未来的需求。

如果发现组里PM不是在辅助项目， 而是在赶着别人干活， 并且抢了所有对外交流的活， 最好的做法是和自己的SDM一起重新定义PM的角色。 这个重新定义的过程中， SDE和SDM应该积极去参与和做一些之前PM干的活， 比较自然地进行角色改变。 好的PM可以促进各组之间的合作， 以及帮助大家扩张视野。

少数组所做领域相关的活都给PM在干， 导致SDE无法学习自己所工作的组的领域相关知识。 比如一个SDE可能在推销组做了两年关于推销的程序， 但是完全不懂得基本的推销方案、无法自主解决基本的推销领域的问题。

这导致这些组里PM权势越来越大…还养成了少数经理什么项目不论大小都要看PRFAQ/BRD的恶习。不是说不应该写PRFAQ或者BRD。 好的组在项目复杂时、投资比较多时， 也是要写的。 但是当时比起PM， 更可能是经理带着SDE写， 而且是不需要写就不写。 现在有些组是能写就写， 而且全是PM在写。这些与亚马逊end to end ownership的理念背道而驰， 也与亚马逊frugality和bias for action的理念背道而驰。

5. 关于薪酬

SDE I其实在很多地方都是看作是暂时的一个角色， 不可长久。 一旦自主能力开发好了， 就是SDE II。 SDE I如果做得好， 顶多底薪增加1.9%左右（我第一年好像只涨了0.1%还是多少）。 但是SDE II做得好， 底薪可以每年增长6%左右（少数可以增长8%-13%）， 直到增长到SDE II薪水封顶。 SDE II开始， 薪水慢慢向股票(RSU)转变。 亚马逊给股票时会假设明年这个股票会涨。 所以每年给的股数可能都比去年少。 这个虽然有时会比较恶心， 最后交税时还是可以看到每年钱在往上涨的。

由于级别比较少， SDE II开始， 每个级别薪水区间可以很大。 西雅图有的SDE II可能一年就10多万， 有的可能20多万， 有的接近30万。这与亚马逊股票浮动关系很大。

总之至少2018年， 就我个人了解：

SDE I: 13万到15万之间

SDE II: 14万到28万之间

SDE III: 16万到???之间

Principal Engineer: 据说比同级别的经理赚得多…

在美国， 员工之间讨论薪酬是被National Labor Relations Act保护的。 阻碍员工讨论薪酬是违法的。 所以大家也可以入职之后找同事了解一下别人的薪酬。 薪酬隐私化是美国传统企业为了削弱员工的议价能力而制造的文化。 但是如果你的同事不想讨论， 还是要尊重别人的。

我觉得亚马逊应该是喜欢留那些以长远目光看问题的人。贝索斯曾经说， 如果你计划做得长， 竞争对手就少。 大多数竞争对手都在看每3个月的财报， 少数可以以三五年做计划。 如果你做计划做到12年以上， 就没有人跟你比了。

所以只要你愿意放长线， 亚马逊给的报酬还是还可以的。

比如，如果一个员工是2012年大学毕业入职， 光他当年4万的signing bonus在2016年全部vest时就已经成了20多万。如果他到2018年都没卖， 就是40万了。

不过话说回来，如果有一个好的成长的机会， 长期的职业发展比这些短期的薪酬要重要。

6. 关于升职

之前提到亚马逊级别比较少。其实升到SDE II是件很不错的成就。 升上去了， 你可以拿拿别的公司的Offer看看给多少。 一般可能会被亚马逊当年给你的工资多一倍左右。

但是从另一个角度讲， 最好着重于成长， 而不是升职。 亚马逊某部门这两年就出了一个问题： 很多系统被设计得过度复杂。 后来调查时发现， 都是因为设计复杂了容易忽悠人好升职。 升上去的人， 很多不称职。

但是大家不要忘了，亚马逊是会PIP人的！能力差的经理一般专PIP那些工作不久的SDE I。 其实SDE I是最不该PIP的。 因为SDE I破坏力最小， 而且最容易训练。

（对了其实现在不叫PIP了）

职位越高， 越容易遇到经验比较足的经理。 这些经理会着重审核SDE III和Principal。有个部门今年一年就开除了两个SDE III和一个Principal。

所以比起升职， 更重要的是成长。 做得好总是会加薪的。做得不好， 升职了饭碗都不一定能保住。

当然SDE I也不要怕PIP。 只要你做得好， 学得多， 你就不怕PIP。 出PIP是件很光荣的事情。 因为一个经理去PIP一个人， 代表着这个经理认为：

也就是说， PIP的确是用来开除人的。

但是如果被PIP的人出了PIP， 就很可能这个经理看错了。 如果一个经理把一个好员工当成坏员工， 最后被开除的很可能是这个经理。所以在亚马逊， PIP是双向的。

这是为什么SDE I其实没有那么好欺负：

所以PIP SDE I十有八九都是错的。一个经理如果经常PIP那些SDE I， 等遇到一个有经验的经理， 就归他自己被开除了。

7. 关于工作与生活

这个也是一个纯粹看经理和个人态度的事情。好的经理着重于提高效率， 坏的经理着重于增加坐班时间。 如果遇到一个坏的经理， 那就得想办法训练他， 或者跟他的经理反应这方面的问题。 亚马逊的小组里， 往往经理比SDE走得快。所以实在无法训练的经理跟上面反应一下把他转走就好。

我最开始的一个组比较幸运， 组里效率比较高。 基本上中午到公司， 午饭一两个小时， 下午5点准时回家。然而工作成就感很高。 谈项目、解决问题、做开发， 都速度很快。 一个中型项目往往也就几周的事情。 而且一两个人能搞定。 每个项目都有时间重构现有系统来让之后的项目更容易。这个组当年是没人想当经理的，因为这个组的经理很累。所有的SDE他都得指导。 每天得考虑怎么样和SDE一起优化开发流程、帮手下的SDE联系上客户、卖项目给高层、应对客户非项目相关的问题。遇到SDE正在走弯路时还得很小心的诱导他走上正轨， 而不是否定他的工作。我们邮箱里24小时都可以看到他在发新的邮件， 不是催活儿， 而是帮组里解决一些琐碎的问题， 帮组员推脱一些客户不合理的要求， 找法务部帮组员研究新功能的合法性等等。这个经理是一个好经理。 虽然我最近发现，有些非常罕见的经理可以做到同样的事情而不会像他那么累。

后来到的有一个组就不太行了。 常常连续周末加班几个月。 全组人都加班， 什么都做不出来。 有两年时间我的休假储蓄都是满的——有假没时间休。这样的情况一直持续到了换经理之后我才知道之前经理做法上的问题。 但是我要是当时就知道这些问题和解决方式， 可能就会给那个经理一些反馈， 让他进行一些改善了。

8. 关于个人用硬件

每年亚马逊都会从员工那里汲取意见。 硬件是2016年以前最大的抱怨之一。 大家都觉得可以frugal， 但是frugal和cheap是两回事。太小气反而会浪费——员工每年开机、修电脑浪费的那些时间相对应的工资都可以给每个员工买好几台电脑了。所以2016年亚马逊给所有开发人员重新配了新的硬件。 包括最新的手提电脑。 最低配也是SSD和16G内存。现在我的Windows Laptop开机就十几秒。 Mac不清楚。

硬件改善也包括重新配置显示器。 可以选择双21寸显示器和单宽屏34寸的曲面显示器。 宽屏显示器做Code Review很好用。 双单屏做开发比较方便。 看个人喜好了。

最近新入职的小朋友表示只能选双显示器。 这是因为34寸的没货了。 可以找IT Support那块申请。 大概要等两个月。

新入公司员工可以选择用Mac或者PC。 这个主要看习惯。 有些组会推荐新人用Mac， 但是如果你没用过Mac， 最好别入坑。 Mac可以直接进行开发， 不用连到Linux主机上。 但是这样开发问题比较多。

PC是带Docking Station的， 很容易就可以和键盘、鼠标、显示器连起来。 Mac的Dock得另购， 不一定能报销（跟自己老板商量）。 没有Dock的话， 这些显示器、鼠标、键盘、电源、耳机什么的就得一条一条插…

2016年以前， 每个人还会配一台Linux的Desktop。 2016年以后已经大多换成了云端的。 可以用手提电脑直接连。

写程序主要是在Linux上进行。 但是有些组至少一半的活都并不是写程序。 做设计、写文档、处理数据， 都是在PC上比较容易。 因为Microsoft Project, Visio, Excel之类的软件， 在Windows上安装比较容易。

当你选好硬件之后， 5年后可以换新的手提电脑。 如果你弄坏了或者想换个或者Mac， 公司会给你换个旧的电脑。 同时5年的排期会重置。 如果出现2016年大更新的话， 倒是可以免去排期。 弄坏电脑的方式有很多种。 我见过人泼咖啡的， 也见过直接用升降桌压裂的。

新员工标准配置是带一张升降桌的。 我用的还是老款的木头Door Desk…主要是我喜欢这样的， 也方便我在办公桌附近搭别的东西。如果刚入职你没弄到升降桌，并且想要升降桌，一定要赶紧跟老板提，因为新员工换硬件比较容易。老员工以前换个升降桌得搞好几个月。 不知道最近有没有什么改动。

9. 关于移民

移民这个事情好像不是亚马逊说了算的。 以前只有SDE II能办绿卡。 2017年开始SDE I只要经理同意也可以办。 当然不是一进公司就立马办。 好像是要工作几个月才行。 现在美国这个情况， 以后移民会怎么样谁也说不准。

10. 关于职业发展

前面提了一些如何应对经理、小组的问题。 这些是主要成长的方式。 在亚马逊其他的学习机会也很多。 比如Principal of Amazon的演讲(POA)， 以及各种”Learning Series”。POA并不需要是Principal Engineer才能去演讲， 也经常有SDE III去讲。

个人觉得， 早期的POA质量比较高。 会谈一些比较基础的东西。 比如我一直对SSL不是很了解， 当时就是从一个老POA里学的， 总算学懂了一时（现在又忘了）。 还有关于Consensus Algorithm， 也是从2007年的老POA里学的。 从2007年的演讲都可以从内网上找到。 最近的POA和Learning Series有部分偏见比较重。 往往让听众拿着一个解决方式去找问题。 这种做法容易造成之前提到的系统过度复杂化的问题。

比如有一次有个人谈Data Oriented Design时， 恨不得把主程序都用data来表达。 自己干脆只写这些数据的解析程序。 这不是不行，但是在大多数场合是过分复杂的。这人为了让大家不提意见， 一开始发言就是”There is no silver bullet”， 来堵大家嘴， 但是到最后也没提这个设计的隐患以及它不该被使用的场合。 只提了句：”It might not fit your use case.” 但是”which use case”恰恰应该是他整个演讲最重要的部分。

还有一次是我没听到的， 但是后来遇到某个组里的人， 他们已经有以event driven的方式做的一些系统， 非常好打理…但是其中一个SDE III拼命想做Process Oriented Architecture。 我从来没听说个这种结构…听他的描述， 这个做法根本不适合他们的问题领域， 反而感觉是把系统做得更脆弱…后来才从他们组另外一个SDE III那里听说， 这人之前跑去看了一个Process Oriented Architecture的Principals of Amazon演讲…然后就盯着不放了…

那么话说回来， 职业发展到底怎么样做最好呢？ 这个可能真的得看人。 但是我现在工作年数也不久， 还处于职业初期（前10年初期， 10-20年中期， 20-30年后期）， 所以一方面只对SDE早期的成长有一些了解， 另也方面也只对我看到的一些SDE有一些想法。 这只是一家之言， 不能以偏概全。 具体上， 有些做法我也提不上来对哪些人不合适， 有些也许根本就是坏的做法， 只是我现在不知道而已。 可以大概想到的就是如果你不在亚马逊， 你的公司也许很难接受下面这些做法。 因为有些公司看待开发者的方式就是“程序员”。 他们不会希望“程序员”去干涉商务， 也不需要“程序员”去建立商务模型。

—2019/05/17更新—

在Adam Barr的新书《The Problem With Software: Why Smart Engineers Write Bad Code》 中， Barr提到， 程序员成长中一个最大的问题就是很多东西都是自学的。 这样导致很多程序员不知道自己不懂什么， 而且还比较自信。 这样容易导致理解错问题、学错方向。 一个常见的错误就是过分注意程序性能而忽略可读性。 这里很推荐在入职前后读一下这本书， 相信对大家的职业发展会有帮助。

————————

10.1 入职

从入职到一年左右， 一般的SDE I最大的学习机会是写程序。 一方面写程序本身是一种思维、建模上的锻炼（熟能生巧）， 另一方面， 小组训练新人最有效的地方是Code Review。

Code Review里面别人提意见多是好事。 当然也要多想想、问问为什么。 一般的SDE II提的意见大概有一半不一定是对的…我之前就经常提错误的意见。 最近遇到有些SDE III甚至Principal Engineer在Code Review上提的也不一定对。 有时候他们是故意的——因为想看新人的自主能力。 如果别人提的是对的， 下次就尽量不要犯同样的错误了。

Code Review的主要目的是培养SDE的习惯， 次要目的是提高程序质量。 有些组（比如我的）有时候拿Code Review来保证程序的正确…这个做法…怎么说呢…Code Review有可能保证程序正确吗？ 有时候的确能找到一些bug， 但是要通过Code Review要保证程序没有bug， 按我一位mentor的说法， “it is an impossibly high bar.” 写程序没bug是不可能的， 更何况读别人写的。 读程序比写程序可难多了。

那么除了写程序、让别人Code Review、做别人的Code Review， 另外一个学习的方式就是把自己组里的程序多读读。 这个是很累的。 我一般最多读几个class就懒得继续了。 只有在oncall的时候为了debug一些问题才能一直读下去， 因为有目标。 这是为什么oncall也是学习很重要的一部分。 不是为了debug， 漫无目的地读程序， 实在是太难受了。

除了这些， 可以考虑看一些2007年左右的POA演讲， 巩固一下基础。 虽然我看了之后还做了笔记都很难记得多少。 但是以后遇到的时候会比较有用。 新的POA我觉得应该敬而远之。 但是带着怀疑的态度去看看也可以。 偶尔还是会有好的。

我看到不少新入职的朋友所在的组里的软件质量并不是特别好。 组员给他们做的Code Review也不好。 但是因为他们是新入职， 所以也意识不到。 可以考虑读一下《Effective Java》的目录和《Head First Design Patterns》。 前者在目录里有什么好奇的可以进去读下。 后者是一本很适合初学者的培养审美的书。 实在遇到一些组里吵架的问题， 比如怎么写test， 怎么做dependency injection之类的， 还可以参考Martin Fowler的博客（直接google相关话题和”Martin Fowler”）。

入公司需要学的第一个设计模式可能就是Dependency Injection了。MSDN上对于Inversion of Control还有Dependency Injection的解释非常清楚。 可以考虑看看。 可能还会因为这个需要去学Guice或者Spring IoC Container。

10.2 写了读了很多程序， 但是什么算程序写得好？

之前提到培养审美， 这里想解释一下程序好看是什么意思。

要理解什么， 首先要理解大多数SDE做的并不是high-tech。我们大多不会在IEEE之类的发表论文。即使在学术界的时候发表过， 现在也没在发表。 大多数SDE的工作是用商务模型所定义的程序来实现以前由人实现的商务功能的自动化。

程序作为商务模型的一个展现方式是写给人看的， 不是写给电脑看的。 电脑看binary就可以了。 电脑不在乎我们的设计， 也不在乎我们的结构。 对电脑而言， Service Oriented Architecture是一种不有效利用资源的规划程序的方式。 偶尔我们要担心一下程序是不是太浪费资源， 但是大多数时候程序是写给人看的。 如果我们优化的是给电脑看我们的程序， 那么所有的程序都该用汇编写， 而且都应该是monolithic的（比如渲染引擎之类的）。

这种商务程序好不好主要在于是不是容易懂。 有些程序过于复杂难懂， 看起来写得很高级， 其实是写得不好。

用“以后看这个程序的人会很蠢而且很懒”的心态下写程序可以预防这个问题。 假设未来看这个程序的是未来的自己， 就很难会故意把程序写的太复杂。 在优化程序设计时， 通常优化的也就是可读性。一个程序容易懂可以减少这个程序被改变、替换时的痛苦， 也就进而让商务模型得到了extensibility，flexibility和复杂度上的scalability。 容易懂也就可以让浪费资源的步骤更明显， 更容易优化， 也就容易提高系统运作的scalability。 容易懂也就让我们更容易debug， 于是bug就更少， 就可以增加reliablity。 容易懂也就让我们更容易看到bottleneck， 也就是更容易增加availability。 所以有多容易懂是测量一个程序好不好的主要方面。

10.3 程序容易懂了， 那商务模型本身怎么做？

模型是某事物的一个表达方式(representation)。

同一个事物可以有很多的表达方式。 每一个表达方式就是一个模型。 模型之间不同的地方在于它省略的部分。 一件事物的完整表达就是它自己本身。

通过省略不同的部分， 不同的模型会更适合不同的用途。

过于精细的模型虽然可以完成原本事物的本职， 但是往往很难懂， 也很难改变。过于粗糙的模型虽然容易懂， 但是却不能完成原本事物的职能。

所以在建模时， 我们会试图把复杂的事物分割之后分别建模， 保证每个部分都比较容易懂， 而又能照顾到细节。 这许多被分割的模型之间的关系， 就是一个更抽象的模型。

想要给一个领域的商务问题建模， 就得了解这些需要解决、需要自动化的问题。

程序写熟、习惯养好这段时间， 慢慢也要了解自己的领域。 做物流， 就得了解物流优化方式；做定价， 就得了解定价策略。 具体的一些建模方面的东西我自己也做不太好， 但是大体方向是针对问题。

建模方面的技术可以参考 Eric Evans的《Domain Driven Design》。 这书很枯燥， 不好读， 但是很有用。入门考虑先读Sam Newman的《Building Microservices》和Fred Brooks的经典《The Mythical Man-Month》 。 后面这两本读起来不会脑壳疼。

以前有人提过这么个事：

很多在SDE II或者SDE III经验级别的人找他做design review时， 会拿6页的设计文件过去。 6页除了一个自然段讲问题， 其他全是问题的解决方法。 他看了之后先会说：“写得很好”(因为不想让别人不高兴)， 然后说：“你用了多少篇幅写解法， 用同样的篇幅去写问题”。 别人再来时， 写了6页问题。 这时他说：“现在你列出这个问题的所有解法， 只是列出来， 不要去想细节， 也别管多蠢”。 然后别人列出来了。 然后他这时说：“现在做所有解法的trade-off analysis”。 于是别人做了trade-off analysis。 然后…然后就没有然后了。 他跟我解释说：“最后他们选了哪个解法， 我其实不在乎，因为肯定错不到哪去。”

在过程的结尾， 这些SDE会对自己的领域更了解， 往往会做出比reivewer能做的更好的选择。

用这种方式产生的6页的设计文件的结构大概是这样的：

前5页讲问题， 最后1页总结解法的选择，外加6-20页的appendix列出所有解法、它们的trade-off analysis、以及更多的问题的研究。

这个过程， 通常是一系列Principal Consultation的过程。 这个过程中， Principal Engineer会带着SDE建立问题的模型， 但是不会给任何答案（有位Principal Engineer提到， 当Principal最痛苦的就是明明知道答案但是却不能告诉别人…）。 SDE会需要去见这个Principal Engineer很多次。 这与亚马逊里有名的Principal Review是不同的。 Principal Review通常是一个完整的文档拿去给一群Principal Engineer看一遍…这个做法很不受欢迎， 因为Principal Engineer很难纠正一个已经投资很多的设计。 Principal Consult最开始的时候一般并没有6页文档。 差不多半页描述一下大概的问题就够了，越短越好。 这样意味着少走很多弯路， 也意味着你在尽早让Principal Engineer了解你解决的问题， 帮助你学习， 而不是在自以为已经解决之后想去找Principal Engineer“盖个章”。

Principal Consult的过程通常能让人学到很多建模的技巧， 以及自己商务领域的知识。 做Principal Consultation是不需要看级别的。 一般SDE II就可以去做。 SDE I也可以去。 当然大多数情况下， 先从最便宜的人用起， 比如自己组里的SDE。 不够用了再往上走。

做了这类活动的SDE对设计基本上有了一定了解， 可以针对问题来设计解决方案。 差不多看看最近的一些POA演讲也不会有什么危害了。

10.4 找一个系统极差的地方， 在那里多呆个几年…

*(2020年更新： 这点可能现在在亚马逊不现实。 见2020年更新。你可以找个系统差的地方学习一段时间， 但是知识也只是一种外在回报。 真正能长久的还是找一件自己觉得有价值、有意义的事情去做。 很多事情虽然很难， 但是不一定有意义)

这里其实是个职业分化的地方。 有些人想停在SDE II养老， 也有的想转SDM， 还有的想继续升SDE III。 我也见过有些Principal Engineer这个阶段转过Product Manager的， 之后又转SDE。

除了想养老的， 不管想怎么转， 有些hard skill和soft skill是通用的。 侧重会不同， 但是都得有。

对很多人而言养老可能是最好的选择。 我以前有不少SDE II印度同事想赚够钱了去泰国隐退。不想升职的SDE II生活是很好的。 平时就带带项目、写写程序， 迟到早退…平时面对的最难的问题往往是选择S3, SABLE, 还是DynamoDB…据说要是是在印度的话工资够买豪宅请仆人和司机。

要是硬着头皮想跟自己找麻烦， 那就最好找一个系统极差的地方， 在那里多呆几年。

如果看亚马逊的Principal Engineer的背景， 会发现他们很多都是在同一个组或一个领域呆了很多年。 他们的主要贡献是对那个领域的建模和开发。 如果没有足够的时间， 很难学到一个领域足够的商务知识。

这个阶段的SDE可以看到周围很多人做的设计并不理想（毕竟选了一个系统极差的地方）。 最常见也是最荒谬的莫过于整个设计都在讨论选什么工具。 一般这种文件都会用”we are researching what is the best technology to use”，”we are using cutting edge technology”， 或者”we are doing machine learning”来掩饰它的不足。一个系统变化最快的就是用的工具。 在亚马逊很多组里是年年被要求要从一个平台上迁移到另一个平台上， 从一个框架上迁移到另一个框架上。 一个系统是用DynamoDB还是S3还是SABLE根本没那么重要（一定要用S3去做high frequency transaction当然还是不太美好的）。 重要的是这个系统的模型是否能有效解决商务问题， 以及未来暂时没解决的商务问题有多容易解决。 即使要谈工具， 也只是讨论从SABLE迁移到DynamoDB能不能少痛苦一点…

这种做法的出现是因为很多SDE以为学这些工具才是technical的， 同时以为商务领域知识不是technical的。之前那个让人回去写6页问题的人就提到：我们行业很多人认为技术(technical)就是指软件。 其实”technical”这个词……（他边说边开始在网上查字典）……仅仅代表有某个领域的专门知识。 比如律师就是一个被规划在”technical”的职位。 他的意思就是， 商务问题是technical的， 让大家不要太过于追求软件工具上的technical。

所以怎么去跟这些“所谓走技术路线”的人交流就成了一个问题。 可以考虑读一下《Crucial Conversations》(Kerry Patterson)和《Yes, And》(Kelly Leonard and Tom Yorton)。

另一个问题是《Domain Driven Design》这书比较抽象， 在老系统已经很差的情况下虽然可以定义目标， 但是很难用来帮我们接近目标。 相对而言，比较具体的人与人之间的交流方式、小组的文化、大组的结构， 与系统设计感觉很相似， 也容易应用。 比如如果两个相关的组物理距离很远， 通常他们开发的系统耦合度(coupling)也不会大。

后来我mentor跟我说这叫Conways Law:

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

也就是说，两个组之间因为交流有障碍， 无法随便假设对方系统内部逻辑， 自然系统之间的耦合度就会减少。

想要优化一个极差的系统， 虽然可以硬头皮上（我认识一个人曾经一手重铸过好几个系统）， 但是如果系统太复杂， 组太大， 就得要考虑是什么趋势导致系统和组走到现在这步的， 并想办法改变造成这些趋势的原因。

10.5 学习Soft Skills和软件架构

这里要谈谈Soft Skills，因为我最近觉得它是软件设计和架构的根本。

网上对Soft Skill这个概念有误解。 Soft Skill下列出的那些管理技术和交流技术并没有错。 但是认为Soft Skill是IT行业产生的、用来区分于technical skill的术语， 并不准确。

我经理有次告诉我， 这个概念应该是来源于军队或者制造业。 早在1950年左右Soft Skills的概念就出现了。 1972年曾经军队开过专门关于Soft Skills的讨论会。 当时IT行业还不存在。Soft Skills的定义是“难以测量的技能”（比如你的工厂里的人是否融洽）。 它相对的其实就是Hard Skills（而不是网上说的technical skills）， 就是一些“可以测量的技能”（比如你一天生产量是多少之类的）。

虽然难以测量， 因为Soft Skills是一些技能， 所以它们还是可以通过学习、锻炼来获得提高的（相对于天赋）。 这些技能是有系统的， 有专业的（管理能力、行为影响能力、政治能力等所相对的学科：管理学， 心理学，政治学 ）。 所以它们也可以说是technical的。

比如”写程序容易懂”这种设计方面的技能因为难以测量， 所以是一个Soft Skill. 但是这个技能可以通过不断地锻炼和学习来提高。 架构方面的技能也很类似。

架构就是所谓的Architecture。 这个词是从建筑学偷来的， 在软件行业里被滥用 。我很长时间都不信这个词。 后来那个让人回去写6页问题的人说， 其实这个词还是有用的， 它指的是把资源、空间以某种方式分配， 让在这之上的设计自然趋向于好的。 简单地说就是架构的就是造成某种趋势的原因。

之前我们提到两个组距离远， 系统耦合度就小， 就是其中一个例子。 如果我们希望某些系统能融合， 把开发它们的小组并到一起就好。 如果我们想分割一个系统， 就把开发它的组员分成不同的小组。

架构也可以是电脑相关的工具， 比如用functional language去写一个系统会让组员更多去思考运算， 更少去思考物件（更有可能会招不到员工）。

现实中， 分组、合组都是很复杂的事情。 这关系到大组结构的影响， 怎么说服别人，怎么用人， 怎么调整过程中和之后的人际关系， 怎么调整每个组的开发流程， 怎么定义每个组的职责等等。这些需要很多针对如何应对、操作人（包括自己）的技术。这些技术往往是无法直接测量能力高低的， 比如管理技术和交流技术。 所以这些技术属于Soft Skills的范围。

因为不论是架构上的改变还是设计上的容易懂都是需要Soft Skills的，意识到每个Soft Skill都是一门技术可以让我们更有效地去探索其中的机制（mechanism）、利用其中通过实验得出的结论， 而不是单纯地利用直觉（intuition）、好的意向（good intention）、和“成功人士”讲的“道理”。

比起从建筑学、工程学借用一些工具， 软件开发其实更适合借用心理学、社会学、管理学、经济学、以及政治学里的工具。 大概因为建筑学和工程学的媒介（比如木头）和限制（比如万有引力）， 都来源于物理。 而软件的媒介（想法）和限制（思考方式）， 都来源于人的思想。

比如我们之前提到， 软件设计最重要的是”容易懂”。 “容易懂” 是认知心理学的概念(cognitive ease) 。 通过学习认知心理学， 我们能够有机制地让软件更容易懂， 而不是单纯地借助直觉。 我们之前提到Conways Law， 它提到软件结构通常来源于部门的交流结构。这是社会学的范围。 通过学习社会学， 我们可以有机制地优化部门之间的交流模式。

理解和利用Soft Skills是软件架构的基础。理解Soft Skills才能知道好的设计是什么样的。 利用它才能给好的设计制造趋势。因此SDE II之后technical path最需要的是系统地学习Soft Skills(当然要走management path也得学)。 我遇到的大多数亚马逊成功的SDE III的Soft Skills都是比较强的。 尤其在沟通能力和处理人之间的矛盾上， 他们大多都很有天赋。 我这方面的天赋不强， 就只能作为技术来学了。

但是我觉得很多SDE III的职业发展的阻碍可能就是没有能够利用Soft Skills相对应的专业知识来有机制地设计架构。因为他们天赋好、有人格魅力， 所以利用直觉也是可以做出不错的架构的。 但是因为缺乏机制， 所以在遇到新的、复杂的、不符合常规的、不符合直觉的情况时， 往往会做出错误的选择。 直觉方面的训练和“容易懂”的意思可以参考Daniel Kahneman的《Thinking, Fast and Slow》。

10.6 我们还是得会写程序的

在亚马逊， 不管是当经理还是当SDE， 都是得会写程序的。写程序是最基层的建模方式。 做发开发不懂得写程序就好像厨师不知道每种食材的味道。

想要解决所在领域的商务问题， 得了解这个领域和它的问题， 用这些知识建模，用程序去创造自动化的方式去解决短期的商务问题， 并最后用架构来促进程序的进化、应对商务需求的变化。

最后我建议大家要养成办公桌上放一本《Cracking the Coding Interview》的习惯。谈工资谈不拢再加本《Elements of Programming Interviews》。

—2020/5更新—

“我们还是得会写程序的”不准确。 当时写这些的时候还是太自大了。

从去年这个时候到现在，通过对自己和同事写的程序的观察。 我发现对于大多数SDE而言， 可能包括我自己在内， 我前面说的的这些不算最佳发展路线。 对于大多数SDE而言， 怎么把程序写得更好是当下主要需要的锻炼。 虽然要写得更好， 的确是需要注意一下soft skills上的培养， 不然会遇到一些阻碍， 但是侧重还是应该在练习和反馈。所以并不是“我们还是得会写程序的”， 而是“大家多写点程序， 并注意找反馈的方式”。

这一段更新中我会反省一下自己的一些问题，并试着更好地描述一下我们职业发展应该做的。

11 再谈职业发展

11.1 我的问题

我的毛病从很小就有老师提到过症状， 说我是脾气暴躁。 不过很多年我都没看到根本问题。 我对自己的评价一直是“比较自卑”。 其实根本问题是自大。 从小我父母就对我很好， 对于我的一切都以鼓励为主。 但是从方式上有一点点偏差： 我做什么做得好他们都认为是因为我好， 所以我做得才好——而不是因为我努力了。

这样让我一直觉得自己是个天才。 如果有什么我做得不好的， 那么要么我一定要把它做好， 要么就是别人衡量“好”的方式不对。

这样的我一直竞争心理很强， 也开不起玩笑。 小学时甚至为了考试成绩跟和我开玩笑的同学打起来。这种竞争心里让我一直很焦虑， 总是害怕自己什么地方不如别人。这也是为什么“脾气暴躁”。

它对于我的成长影响很大。 我一旦看到不如别人的地方， 也不会顾及别人的“强项”有什么意义， 只会自顾自地一定要做到比别人好才行。 而那些比不如人的地方， 就会找别的方式开脱。 比如像文章之前谈了很多soft skill， 虽然道理不一定有错， 但是从出发点而言， 恰恰是因为我觉得自己技术不如人， 所以就想改变测量方式， 多注意别的能力。它们的出发点不是“如何变得更好”， 而是“如何让我比别人强”。

这种自大不仅让我活得很累， 还让我没有办法有效地分析他人。 在看人时， 我不仅可能过度贬低别人， 更可能因为自己知道自己不喜欢别人比自己强的事实， 而过度抬高别人来调整偏差。 抬高之后又会贬低因为怕抬过了。 整个分析过程完全是在对抗自己的自大、针对别人的强项来产生自我保护的反应， 而不是客观分析对方的能力， 并且接受自己可能分析错误的事实， 并根据更多的信息来进行调整。 所以我看人经常看错。

自大的我是不能接受错误的。 虽然因此我做事会更小心、更努力、更多地责备自己的失误， 但是也让我很难接受他人的批评， 更难接受新的数据。 这让我经常花过多地时间去做计划、做预测， 而在现实不符合计划或预测时很难凑合、适应。 过度反省让我失败时很痛苦， 也让我很害怕重新尝试， 进而在我做得不好的方面降低了我尝试的频率。

自大的人对于发现自己不如人时的可以有几种反应。 我的反应在有些情况下是争强好胜， 有些情况下是放弃。 前者逼着我学了很多东西、锻炼了很多能力， 但是却也让我一直处于焦虑状态。 同时， 它也让我无法根据一个我自己想要达到的目标来训练相关的能力。 我的能力的投资是根据身边的人的强项来分布的。 这很愚蠢：我的同事和朋友已经在某方面比较强了， 为什么我还需要在那个方向过度投资？ 与他们合作不就好了？ 顺便还可以跟着学习。

没有办法看到别人的价值对我的合作能力有负面影响。 从自大的我的眼中， 别人有价值这个事实似乎在说我某样不如别人。 因此与人合作这个事情， 我一直是空有理论， 而实践起来非常艰难。即使合作了， 也经常是让别人做我做过一遍的（这样就可以保证别人做的不会是我做不了的）， 或者是完全不干预（这样就不会看到别人比我做的好的地方）。 这种合作效率非常低。 出发点不是“如何帮助对方来帮助我”。

看不到别人的价值， 也就无法认真考虑他人的想法和尊重他人。 这也是为什么我会对人很暴躁。 而因为我看到的只是暴躁， 所以很多年一直是靠压制， 而并没有根本上解决问题。

11.2 怎么样过这道坎

我这两年这位经理虽然也会讲很多道理， 但是更多地是让人去通过实践和反馈来理解问题。 有些人过于胆小， 需要鼓励他们去实验尝到一些甜头。 有些人过于鲁莽， 需要鼓励他们去实验尝到一些苦头。

像我这种比较复杂。 他需要让我理解很多理论知识， 并且让我在良性合作上尝到甜头， 让我在努力实验、甚至失败上尝到甜头， 让我在无视技术、过度理论上尝到苦头， 让我在过度计划和设计上尝到苦头，让我在过度消极预测项目进展上尝到苦头，以及让我在恶性合作上尝到苦头。

这个过程他花了两年。 如果没有这个过程， 也许我一辈子也无法过这道坎。

从具体操作上， 这位经理跟我父母一样， 也是以鼓励为主， 但是让我自己去体会各种反馈。 他本人只对努力发出评论， 而且永远是正面评论。 因为他从来都不谈结果上的反馈， 所以很多反馈都只能我自己去发现和体会。 虽然很多东西我开始体会不到， 但是实践多了就可以体会到了。

他让我主要去看Dunning-Kruger现象：当一个人某样能力太差时， 他是没有评估自己能力的能力的。 比如人们发现有70%的司机认为自己比50%的司机开车开得好。 那么这里至少有20%的人不仅不如50%的司机， 而且还认为自己比50%的司机开得好。 这个现象的原因就是他们开车水平太差， 已经无法自我评估。

这也是为什么很多人在考试的时候， 往往恰恰是在觉得自己考得不怎么好的时候考得还不错。 因为那些人在那个时候已经具备了一定的评估他们自己能力的能力。

一个人如果没有评估的能力， 那么也许他只能依靠反馈来成长？ 遗憾的是， 当一个人没有评估能力时， 他会很难理解这些反馈。 比如撞车了总认为是自己运气不好或者是别人的问题， 考砸了觉得是自己偶尔粗心或者问题太刁钻。像我这种比较自大的人， 即使非常努力地去找反馈， 还是会有非常大的盲区。

这样的状况下， 跟我讲道理、给反馈， 用处都不大。 唯一有用的， 就是鼓励我去失败。 在不断练习的过程中，自己吸收一些我能接受的点点滴滴的反馈， 以及熟能生巧产生的认知， 都会让我慢慢提升能力， 和对能力的评估能力。

在《Outliers》一书中， Malcolm Gladwell提到， 在他们的调查中发现， 即使是天分最糟糕的小提琴学生， 在得到一万个小时的练习之后， 也会成为世界级的演奏者。 而即使是最有天分的小提琴学生， 如果他只有一两千个小时的演奏经验， 那么他最多只能当一名小提琴教师。 他们之后去调查了各个行业， 发现几乎都有这样的现象。 “成功”的人， 几乎都在他们成功的方面有过至少一万个小时的练习。

这个现象即让人谦虚， 也给人带来希望。 谦虚是在于它让我反省我到底有没有在我自认为很强的地方里面投入足够的练习。 如果没有， 我又怎么能确定自己真的在那个方面很强呢？ 天分走不太远， 最后的能力主要来源于经验。 如果我没有足够的经验， 那别人比我强也理所当然。 希望在于， 即使我的天分再糟糕， 我如果能够花时间和精力去做， 那么我迟早也可以做到很好。起点并不能决定终点。

之后还有一个关键点…就是练习什么， 什么就更强。 如果我练习的只是写程序， 而不在乎项目的成果， 那么一万个小时之后， 我会成为一个程序写得少有人能比， 但是项目却还是可以做得一塌糊涂的人。 如果我只在乎单一项目成果， 但是不在乎他人的培养和我个人的可扩展性， 那么一万个小时之后， 我还是无法有效与同事互动完成更大型的项目、而我完成的项目很可能长期而言有各种扩展性方面的问题。

所以对于练习， 我们需要设置一个足够宽广、单纯，又可以实现、测量的目标。 我的经理因此一直说， 他觉得唯一一个让他没办法的事情， 是一个人的意向。 意向不够单纯很难设置一个单纯的目标。 让一个人练习项目开发和员工培养， 他可能满脑子都是如何升职， 如何让自己得到升职的筹码， 反而忽视了项目的开发和员工的培养。 简而言之就是目标设置得太小， 因此练习的东西也不够达到一个完整的结果， 更无法看到完整的反馈， 会有很多盲区。

在软件行业， 我们的反馈来源很多， 但是也比像拉小提琴这种事情复杂很多。 比较难的一点在于， 一个项目的反馈（系统的稳定性， 可拓展性等等）往往要几个月甚至几年才能慢慢出现。甚至最直接的客户体验， 也需要项目结束时才能看到。 这样我们如果一个项目一个项目地做， 在这方面的反馈可能一年只有那么几次。 像写程序是否compile， 拉琴是否音准这种的反馈， 几秒钟就可以得到和更正。 反馈不够多是我们成长后期比较难以解决的问题。 这是为什么往后走一定得同时与人合作多个项目。 如果一年能与人合作50个项目， 那么两年之后每周就都可以得到很多反馈。 这点可以从小开始做。 50个项目早期基本上是不可能的。 每个人吸收反馈的能力和习惯也不同。 所以还是得从个人需求出发， 与经理讨论如何才能得到足够的反馈。

—2020/4更新—

2015年人力改革有很多弊端。 现在在一些经理比较差的组已经开始显现。我2020年的更新一直在反省自己。 其实回看会发现很多问题来源于组织从上而下的腐烂。 并不是什么事情都从自己身上找问题是正确的做法。这样做有时会很危险。

比如一位经理， 技术能力极强， 但是因为以前当SDE时升职没升上， 一直在自己身上找问题， 并试图合理化。 他的结论是自己技术不强。 在他管SDE时， 一旦SDE接近他当年想升的职位， 他就会出现误判：因为SDE的能力不如他， 但是他又自认为能力不强。

我自己也发生了这样的事情。 我觉得自己不强， 结果在判断某些SDE的升职时， 没有进行客观的判断。 对一位SDE的能力错误地判断过低， 而延迟了他的升职。 对另外在某些方面比我强的SDE错误判断过高， 过早地让他们升了职，进而破坏了他们之后的职业发展。

之前提到的在系统很坏的地方呆几年， 事实证明可能是一个错误的做法。 至少在现在在亚马逊并不现实， 而且极可能所有的付出都得不到认可。 归根结底， 学习和进化， 也是一种外在回报。 真正能持久的， 还是去做一些有意义的事情。 一个系统坏， 你可能能学到很多东西， 但是这不代表是有意义的。 一个坏而对客户没有价值的系统， 你把它弄得再好， 也是没有意义的。 很多事情可能很难， 但解决它不一定是有意义的。 我以前这种见到难题就想解决的做法， 仅仅是一种自我满足罢了。

即使付出得不到认可， 如果做的事情有意义， 一个人还是可以坚持下去的。 但是如果做的事情本身意义不大， 就很难在别人的误解下还坚持下去。 盲目地去解决难题让我得到了很多成长， 但是最后我觉得很疲惫。 一个人应该自己去定义什么是有意义的。 可以是对他人产生价值，可以是赚钱，可以是对社会产生福利， 也可以是自我成长。 至少对我而言， 我发现“自我成长”无法在逆境中让我觉得有意义。 而“对他人产生价值”却可以。

—2022/2更新—

如果你读到了这里， 或者只是把页面拉到了这里， 那么我很欣慰。 这两年我的能力得到了一个完全不同的水平和阶段。回头看， 我说的很多东西也许都是误人子弟。 但是接下来说的， 我有信心会真的对你有所帮助， 因为我在实践中反复验证了它们。

讲一下我2020年以来的经历吧。之前没有讲太清楚。2020年初，我就感觉到自己的产出有些问题。 从2018年开始就一直觉得自己带的项目太少、太小、质量低。 一方面我也的确不喜欢我们的产品，所以大多数时间都在辅导别人、让别人带大项目， 或者纸上谈兵地聊架构。我当时不知道其实我就已经上了dev list。 这点经理不需要告诉你， 所以你上了也不一定会知道。这个流程嘛， 反正就是给你项目做， 然后在项目中搜集数据， 决定是否进pivot， 也就是我们过去所说的pip。我们还是直接叫它pip吧。

2020年我做了一个比较大的项目。 这个项目当时我觉得是一个难度极高的项目， 而我在设计、人才调用、和执行上， 已经很努力了。 回头看， 当时 有很多选择都耽误了我的努力。 设计上也许有更简单的解法， 人才调用上我更应该多兜底更麻烦的部分， 执行上我的项目流程还是太松散、没做够调研， 导致有很多纰漏需要别人来弥补。

现在的我， 可能会把这个大项目变成一个小项目。 至少变成一个中型项目吧。最起码我会把项目开销降低一半， 质量也会增加很多； 会更早地和产品经理沟通去简化用例；会自主去做其中给我的同事带来很多问题、但我可以更轻易做出来的部分；会做出优秀的例子、作为模范去帮助别人成长， 而不是过度手把手地辅助对方做一件远远超过他能力的事情。

2020年年底， 我正式进入pip。 原因就是项目执行、设计上， 都有纰漏。 当时我跟与我共事的同事都不服这点。这几年很多人也在关注我什么时候升PE的问题， 甚至2020年年初还跟经理有过一些讨论。大多数人还是认为我非常优秀， 进入pip不可思议。回头看， 其实我就是我自己说的， 造成负面影响的、应该被pip的SDE III。至少2020年的项目， 并没有能体现一个接近PE的SDE III的能力。

我当时分别问了上面两位经理， 你是希望我留下， 还是希望我走？

一位经理说：

另一位说：

实际上，当时， 即使到现在， 也有少数人对我的能力有所猜疑。 有些猜疑是对的， 有些是错的。

反馈这个东西， 有三道坎。

第一道坎， 是给予反馈的人， 很难看到准确的问题。 他给你的反馈往往是症状， 而不是病因。这点上， 你需要优秀的分析能力才能正确理解反馈。你也可以找个导师帮你分析，但是他也不一定有这个能力。

第二道坎， 是很多反馈， 甚至是错误的、是对方能力不足， 才看不到你的好。 这种反馈跟第一种反馈又融合在一起， 难以分辨。

第三道坎， 是自己心里这道坎。 我们还是不愿意接受批评的。 但是什么时候我们不愿意接受批评是因为这个批评错误， 什么时候是因为我们没从症状理解到病因， 什么时候仅仅是自己不情愿、自己骗自己？ 区分这三点太难太难。

去实践， 才能检验到底是什么情况。

所以我当时对于pip， 有很多迷茫。 我也不确定是自己的问题， 还是别人的问题。

第二位经理给我的pip花了很多精力。 他设计了三个任务让我在4周内完成。 我从任务内容中可以看到他花了非常大的时间和精力。 这些任务的确可以在这个时间内完成， 而且也是我感觉做起来会比较有意思的事情。 这是去做三个项目的设计， 有大项目， 中项目， 小项目。 其中小项目要求写出程序。

当时我内心里还是不服的。 因为很多人说我设计好。 但是从另一个方面讲， 我那些年审核设计并不顺。 而且自己设计也不够多。 任何能力， 如果你觉得你很厉害， 但是做得不多， 那么大概率你是被Dunning-Kruger Effect所欺骗了。 你强不强， 只有用实践去验证。 这不代表你不会失败，失败恰恰是成长的关键， 而代表在不断的实践中， 你可以知道什么事情你会失败、什么事情你会成功， 以及你接下来要怎么去失败。

当时我还在花80%的时间去辅导一些新人。 但是一进pip， 我的所有的时间都可以专注在设计上了。 这4周， 是我职业生涯得到最大飞跃的4周。

我当时已经很久很久没能静下心来做自己的事情了， 都是在操心别人的事。pip反而给了我这个机会。

经理在pip开始前给了我不少时间。 期间我在九章算法上了个系统设计的课程。 本意是准备面试， 却惊喜地发现九章所教的很多案例， 刚好帮我总结了我多年的经验， 让我的设计能力得到了真正的提升。类似的资源还有Grokking的System Design Interview课程， 以及Alex Xu的《System Design Interview》的书。

到了pip这4周， 我需要快速做出三个设计。 这逼着我非常专注于实践。 第一个设计是一个大型项目，我很快写出一个版本， 然后从不同的人那里得到反馈， 进行迭代。 我迭代了很多次才勉强满意。 第二个设计是个小型项目， 我吸取了之前的经验， 几乎一气呵成。然而这两个项目我都太注重细节了、有些关键的地方没能专注——这恰恰是我之前项目能力有问题的根本原因。第三个项目是个中型项目， 我通过前面在细节上浪费时间的教训，学会了划重点、做大纲， 一天调研就把重点弄清楚了。 第二天写的大纲就已经让所有人认同， 后面的设计只是走过场。

顺带一提， 现在让我做这三个设计， 只需要一周， 而且肯定比2020年做得好。

之后在pip审核时， 难以避免地还是有个项目有些争议。 高层有个人自己能力不足， 审核我的东西也有一些偏见。据说第一个经理非常强硬地给我力争。最后在拖延了几个月之后帮我拿下了一个肯定的答复。之后我换了同经理下的小组。实际上相当于把我的影响力增加了一个组， 因为我并没有停止和之前组合作。

而这之后发生了一些神奇的现象。

为了验证第一个能力， 我自己从头到尾做了个项目——从产品设计， 到系统设计， 到执行（执行时当然也带人）。 结果非常好。 项目总体上的开销， 比起一个我以前可能做的设计， 节省了90%。 是的， 我把一个常规会需要几个SDE年的项目， 六个SDE月就做完了。而且维护成本极低、系统很简单。

当然这样也许还说明不了问题。 我又去找了个别的SDE I的项目。 给了一些简单的技术选型的建议， 划了几个重点、标明了几个会出问题的地方。 这个项目非常类似于我之前组有人做的一个项目。 当时那个项目大概耗时9个SDE月， 也是一位SDE III辅导一位SDE I做的， 之后维护成本一直挺高， 到现在还没排错完， 经常出问题。我辅导的SDE I只花了两个星期就做出来了， 而且他的解可以给我的老组用， 而且几乎没有维护成本。

关于第二点， 主要是在这些会议后得到了当事人的肯定。 有些人甚至跑来跟我说， 我既然能预测PE和Sr. Manager会怎么说、会怎么想， 他们为啥还要去找PE? 我说我又不是不同意你的那个人…

最后那点比较难验证， 但是也有迹象。以前我辅导的SDE感觉都在原地踏步。 2021年开始我辅导的几个SDE， 都升职了。而且我都是抓着他们职业瓶颈、针对升职反馈在培训。 所以应该有我一份功劳吧。

以前我一直觉得自己很聪明、潜力很高， 但是你要问我说我能力接近PE了吗？ 我可不敢回答。 答是吧， 感觉很自大， 答否吧， 感觉我又咽不下去这口气。 但是我现在知道， 我的多项能力已经达到甚至超过少数PE。 虽然我还需要去通过实践去展现和证明这点，但是我现在知道自己的能力在哪、自己需要进步的地方在哪。 而不像过去， 能力差到还不足以衡量自己的能力。

得到这些能力的转折点， 恰恰是这个pip。 pip让我不得不去面对失败。

所以至少我的pip, 名副其实地做到了它”performance improvement plan”应该做的事情。 pip流程本身给了我很多实践的机会、不怕失败而勇往直前的机会。 pip之前九章算法的课程让我有了总结、学习案例的机会， 看着别人的案例， 让我有了虚心反省的机会。pip之后我在跟其他公司面试过程中， 又通过了解别的公司、了解那些那面试官， 得到了很多可以反省的材料。

最终，在2021年进行了不断的反省和实践后， 我的系统设计能力、技能传授能力、组织影响力、组织运筹能力、产品设计能力、项目执行能力都达到了一个以前无法想象的高度。

这个改变让我学到了一项关键的技能：就是提升能力的能力。

其实这个技能非常简单。 它就是去实践、去失败、去反省。 我过去的做法， 很大程度上依赖于我的分析能力， 而不是经验。 一个项目我会很细致地去分析， 避免失败。 小项目这样做没什么。因为小项目变数少、需要考虑的少。 全部都考虑好了， 就行了。 但是随着项目越来越复杂， 我需要考虑的事情是呈指数型增长的。 所以大项目不划重点， 根本没法设计。

但是因为我所有的项目都靠分析所有来做好， 我从来不知道什么事情可以被忽略， 什么事情需要被专注。

而2020，2021这两年间， 我不断地体验了失败和成功， 不断地总结了自己和他人的经验，这才能够划重点了， 并且意识到了， 其实几乎所有的能力， 不外乎于知道怎么划重点（也就是知道需要专注什么、可以忽略什么）和养成习惯。甚至划重点本身也是一种习惯。 而这只有通过经验才能有效达到。

一旦做到了划重点， 我多年锻炼的分析能力、跳出框框思考的能力， 突然就成了一种超能力。 已经划过重点的东西， 我分析起来跟玩儿似的。 当然你可以看到， 我不太注意的时候， 写文章还是一如既往的啰嗦（如现在）。

我发现我这么多年， 就像一个故意饿自己的人。不给自己失败的机会， 让自己没有足够的信息、经验去总结和分析。 开始接受失败后， 我熬出来的分析能力， 让我能够由少量失败去得到比常人多得多的成长。

这不代表你应该如此。 正面地去锻炼， 去得到经验， 好好消化， 比这样变态的培养可能更有效。你的案例会更多， 你的分析也会更到位。

长期地去训练某个能力、体验失败、并反省， 其实是只有少数人能做到的。 像我， 在工作了近十年后，才总算有了失败的勇气。

至于亚马逊， 我会把我的附近做好、改善局部问题。事实证明， 亚马逊的内部还是会注意到问题， 并且勇于改变的。 但是这些改变往往有些延迟。 而且局部问题根据情况不同， 可能需要更久才能真正改善。