Ep 49. 大公司非业务部门的困境
59:03 Share

各位听众大家好,欢迎来到最新一期的捕食者说这期我们非常高兴请到了前 React Team 的孟迪来聊一下大公司非业务部门的困境我们先请孟迪跟听众们打个招呼吧

Hello 大家好我的名字叫蒙迪我在网上也用一个网名叫陈光我是原来 React Core Team 的 Developer Tooling 的一个工程师然后其实去年已经离职了现在在一个做 AI 的 Startup 工作今天也是第一次来到这个节目非常高兴和大家分享我的一些经历和看法

好的谢谢孟迪然后我们另外一位主播是赖兴涛哈喽大家好我是兴涛对今天就我们两位然后对然后为什么聊到这个就想到聊这个话题呢是因为之前看到孟迪写的一篇文章叫做对 react 团队工作经历的思考里面聊到了很多就是 react 团队的

的一些困境吧然后联想到就是 Google 之前也发生过裁掉整个 Python Team 的事件那我们就觉得就是像大公司非业务部门遇到的一些困境其实可能在各个公司都是通用的因此这个话题可能也会比较有意思然后我们不如先请孟迪分享一下他在那篇文章里写的包括以前在 React 团队工作的一些经历吧

好的,我在 Meta 工作了非常多年,一共有差不多五年不到一点,但是我是后来一开始在其他的部门工作,然后在 22 年来到的 React Team,当时 React Team 可以说是我的梦想吧,就是做前端工程师很多年,然后 React Team 可以说是在前端领域最有影响力的团队吧,当时也是觉得非常的骄傲,

不过怎么说呢有点好景不长就是加入没多久

当时这个当时公司在之前一段时间因为美国这边有很多的包括降息啊包括经济上的刺激啊很多科技公司都在扩招但是到 22 年正好就是急转直下很多公司都开始裁员 Meta 当时没有不是第一批开始裁员的公司但是也停止招聘了当时我们在 DevTooling Team 在 React DevTooling Team 原来说好有五个 Headcount 结果变成了两个就是就是

就是我们原先有三个人加上两个准备招聘的 headcount 然后结果刚刚辞职了一个人然后我们本来准备招三个人进来结果一个人都不让招了就变成了两个人撑整个 team 然后但是这个 team 的工作量是一点也没有少

我们去开会去讨论我们组现在要做什么的时候呢公司里包括我们自己的部门自己 REAC core team 其他的人包括一些兄弟 team 像 REAC native 也包括公司其他部门的一些 Meta 有一个 develop toolingdevelop experience 的这么一些组包括什么叫 web speed 的组他们就来了一大堆的工程师提了大概我们写了一个剧场的文档每个人都在那写了五六十个不同的想法吧

然后很多人都说我们要 react 要做行业标杆我们这么大的名气要配得上我们的 dev tools 要配得上我们在行业中的地位

但是现实是 react tools 其实它最主要载体是它的 chrome 的扩展然后还有几个它放在几个 mobile 的工具上回头介绍一下这个你说的 chrome 扩展它具体是用来做什么的吗就是它怎么去方便调试 react 因为我其实我不怎么写 react 对是应该介绍一下因为这里的听众可能很多也不是做前端的是做 Python 的为主吧

DevTools 作为一个扩展是它会在你 react 的那些我先介绍一下背景 react 是在 HTML 上面做了一层抽象的这么一种 view library 那么 react 里面那些所谓的 components 它对这些 HTML 没有一一对应的关系然后 react component 又有自己的 state

那么就是说用浏览器自带的 DevTools 是没有办法去拿到这些信息的所以 DevTools 最基础的概念就是去帮助大家去 react 开发者做开发的时候能够很方便拿到这些信息并且可以在 DevTools 里面就是现场去调试

然后包括帮大家做一些性能上的判断做 profiling 比如说它有一个功能就是说它可以在网页上去画就是说哪里哪些 component 重回了重新更新过了它会在上面显示这个颜色

这样子就可以帮你判断说你有哪些地方好像你觉得其实不应该更新的但是它却更新了就很直观会有很多这样的功能包括更深的我就不说了吧很多东西可能是只有 react 才有一些概念但这些东西都要从 DevTools 里面去给到开发者让他能方便的去查找到这些相关的信息但是这些工具的他们的 API 是一直在更新的

呃然后我们去跟进维护然后解决上面的 bug 都已经很忙了就是我们只有两个人嘛然后当时就开会的时候舔着脸问说谁能贡献一部分时间来帮我们做一部分项目呢呃结果大家都说呃好像有其他的有限级的项目哎可以打断一下吗就是你们开会像提需求的人他们是哪个哪些 team 的呢呃都有吧提需求的主要是呃

我印象里提取最积极的是其实是 react native 那边的其实说 react native 我刚刚昨天看到原来他们 react native 的同事自己把他们原来想在 dev tools 做的事情做了他们刚刚昨天发布的也是过去两年了吧他们终于抽出时间来把这些东西做好了

也是我还是感觉挺欣慰的确实当时我也能感受到 DevTools 对 Red Native 当时的支持并不好

他们碰到很多问题就不能像 web 这边这样方便的去调试那 web 这边也有很多的问题我们也收到很多的想法是来自于 web speed team 也是我们的一个兄弟 team 他们就是负责保证这个 facebook 其他的这些产品主要是 facebook.com 还有 instagram 这些产品在 web 上的体验是好的他们的加载速度是很好

这么一些他们做这方面的工程那么他们也提了很多的意见和想法但是确实 React Native 就是有一种难以忍受就是一种不及格的感觉其他的都是有种井上添花的各种想法但其他的像 React Native 这边确实是提了很多对他们来说有点雪中送炭的这些需求所以就是但你们又人手不够那你们最后是怎么就

怎么解决这个问题怎么解决就是只能跟大家说我们要排优先级那么最优先的要放到最前面很多东西就开始无限的往后拖嘛

当时团队里有一个我觉得不太好就是管理上有点出问题的地方就是很难去真的拒绝一个需求就是只是把它优先级排第一而已然后我们的 roadmap 就是一个巨大的文档然后只不过其他的就基本上大家可以当时我们叫 P0 嘛 P0 就是说必须要做的项目然后有所谓的 P1 项目就是说 P0 做完了之后 P1 尽量要做完

当时这个 team 的情况就是 P1 都不要想把 P0 做完 P1 意思意思就可以了一般来说公司的标准就是大部分工程团队的标准应该是 P2 才是可能意思意思或者就不做了但是我们那边就变成了连 P1 都基本上推进不了的程度当时还正好碰到一个很不巧的情况就是 Chrome

当时要推叫 Manifest 3 就是他们的 Chrome 扩展有一套新的 API 那么这套 API 是强制所有人必须跟情当时其实他们很早就要推这个事情

但是那一年是他们很早就打好招呼说今年年终我们一定要切了就是到那个老版本就不能上新了老版本就不能在那个 Chrome App Store 上面更新了所以那个也是必须做的就变成了一个虽然没有什么体验上的更新也没有新的功能但是却必须做的而且也很复杂的一个项目

所以当时真的是大概是 23 年上半年吧我们做 planet 真的是头头大对那这种确实很头疼那我想问一下就是像你们 DevTools team 和 React team 的关系是怎么样的

DevStore Team 其实就是 React4 Team 的一部分但是一部分吧当时我们有想过把它拆出来为什么有五个 headcount 呢就是拆出来然后可能把名字就改做 Developer Experience Team

然后就单独分一个 manager 单独立一个就单独的这么一个 team 当时也是这个 vision 给我画了这个饼我去的时候但是之前是一直是 core team 的一部分而且其实一直人手就不多

然后原先是就是其实 core team 的很多人会主动的像 Dan 就是主要是 Brian 当时做这个事情很多但是其他的人也非常关心 DevTools 的事情会主动的做很多新的功能但是到我加入的时候其实很多包括 Dan 当时已经准备要离职了 Brian 也准备要离职了然后

其实已经大家 core team 的其他人也忙于其他的事情就很少来参与 DevTools 这边的事情然后当时我加入的时候本来是说要拆分出来但最后其实也没有拆分就是 core team 的一部分然后这个 team 的位置也稍微有点尴尬因为其他的因为他做的事情吧就是说你去做这个扩展你好像是在做一个产品你要去跟你的用户去聊用户是其他的开发者

其他的团队的工程师那么你要跟他聊你可能甚至要把这个界面做的好看一点做的符合直觉一点可能要做一点设计然后做一点用户调研明面上是要做这个产品但是实际上它内核是就是需要你对 react 的内部的 internal 那些东西非常非常熟悉才能在上面做开发

当时我其实在离职前也想做一个项目据我所知现在应该也是进展不多吧想做一个项目就是说把 reactor internal 的那些 core part 最核心的那部分像 fiber 那些东西完全从 DevTools 里面剥离出来但是这个项目也是

命途多舛吧就不多说了剥离出来的目的是什么呢剥离出来的目的当然是就是说以后 DevTools 的工程师不需要知道那么多的 Internal 的那些像 Fiber 那些东西另一个目的就是希望 Core Team 其他的人在做重构或者说加新功能的时候不要束手束脚因为 DevTools 最多的

也不一定说最多就是那些我们最头疼 debug 起来最最难受的那些 bug 都是 core team 其他人搞的就是 react 的一个新版本加了一个东西或者改了一个东西结果那个版本在 devtools 上就不能用了所以后来其实

团队里面我们当时也是开了很多会怎么样去为我们争取更多的资源当时在那个 Hirefree 这个决定出来之前部门的老大其实跟很多其他部门去开会去要资源然后我就发现他回来之后就开始给大家强调要去做 VR 当时那个 Facebook 改名叫 Meta 这个事情我想大家可能还有点印象了

为什么叫 Meta 就是 MetaverseMetaverse 这个愿景就是用这个公司的 ARVR 这套产品去支撑的那么这些东西在公司里是非常受重视他们有非常多的资源至少在当时是这样子然后当时我们台队老大就是从那边要来指示就是说他们用 React 去写他们的 ARVR 那边的 app

那么我们就给他们做支持那这样的话就他们就我们就可以拿到更多的资源去招更多的人这里的支持是指 sorry 这里支持是指就比如说方便在 VR 设备上的挑事吗这种不是我我们 DevTools 这边的给他们做支持而是说因为那个东西是非常新的相当于一个新的操作系统

因为它的这个 AR VR 的体验和我们平时用的这种二维的这种屏幕是完全不一样的当然也有相共通的地方那么里面的一些比如说像一些 VR 的游戏那肯定不能用 VH 去做但是里面也可能有很多这种

更传统的像界面一样的东西对吧就说你有一个 app store 吧对吧你要点那个导航菜单吧你要点这个购买按钮吧你要填一个表格吧像这些东西其实用 react 去做是非常非常合理的明白了那它里面还是 electron 那些吗不是呀它是它内核是安卓的内核好像那么后来我有点

不敢说了因为他们这个技术角色好像变了好多回但是是全部都是 native 所以就相当于重新做了一版 react native 可以跑在 meta 的那个 quest 系列的设备上那就是用户还是可以写 react 的代码然后 react native 就是把 react 跑在那个新的系统里面

是的 是的 只是就说它的相当于编程语言上有一层 DSL 可以这么理解就是写成有点像做 web 开发那套样子但是它其实会直接渲染成那个系统里那套界面 OK 对 所以当时其实所以我想说其实就是说这个也是说就是不只是 DevTools 碰到了这种

这种困难吧整个整个组整个部门都是如此只有跟公司最重视的项目扯上关系才能得到资源那这里当时有些更希望能更专注于做 web 方向的一些大佬级成员像像 Sapp 像 Andrew 他们后来都去了 Vasal 就是因为 Vasal 可以给他们这方面的支持让他们专心做这件事情所以他们就就另谋出路了吧嗯

所以其实我和一些做前端的朋友都有这样的困惑就是外面就不说了 react 在 meta 里面是所有地方都用的都是 react 那么而且在外界在业界里面也给 meta 带来很大的名望既然是这么重要的项目 meta 这么大一家公司赚这么多的钱为什么不能去多投入一些资源然后

我碰到这些困难之后,就包括当时刚才也提到说像 Google 的 Python Team,像就是跟 React 更像一点,像 Flutter 和 Dart 这些的 Team 都有碰到类似的困难,也遭受了裁员。我觉得推广开说做 infra 或者做 platform engineering 的这些团队,你们不

不直接去给公司提供商业上的价值的我后来总结就是或早或晚都会碰到这样的对我方便问一下当时比如说 react team 有多少人就算上做 tooling 和 core team 就所有这些大概是个什么量级算上做 debt tools 和 core team 大概有不到 20 个人然后 react native 那边又有很多

其实人还多一点可能差不多吧也是 20 个人吧对你要问我直观感觉我觉得 20 个人看起来是不少的对吧但是想对于 react 的这种这种用户的基数来说它可能是不够的而且我理解它还有一些比如说内部需求和外部需求的差异有一些就是是有一些不同的对吧因为至少在 Google 是这样子

我们长期会维护一个专门发布给内部用的版本当然一些就是实验性质的这些功能也会先在那边发出来包括 DevTools 也有一个专门给内部用的然后 20 个人是算上所有的 Manager 算上 Manager 算上 Developer Relationship

而且现在你去那个 Media Team 那个页面里面我刚刚看了一眼是刚刚好十个人就是在 Meta 的刚刚好十个人其中有三个三个半是在做什么呢做那个叫做 Forget 他们可能叫后面后来改叫 Compiler

在做 compiler 他们就其实完全不碰 react 的代码他们是当然那个项目现在也在 react 那个 repo 里面但是他们是不做 react 本身的开发然后他们是做一套 compiler 去给 react 去怎么说呢去把它自动的做性能优化这么一套东西

如果假如我是说假如这十个人做的那个 react 如果是一个商业项目的话它有这么大的用户体量我觉得完全足够就是一家小型的创业公司了就算是只给 1%的客户咨询应该也够了像那个 view 的游小悠我不知道他赚多少钱或者怎么着但是他自己有家公司反正

但是但是 react 是 Facebook 的资产对吧这样是行不通的就是我感觉就是对于 Facebook 这样大的公司就是因为这个事情对他来说相比他的收入他一点都看不上但是如果如果单独把它拿出来的话这么大的用户体量我觉得就是无论任何商业模式都很容易成功因为因为我知道的大部分公司都在用这个前端

还有对 VU 跟 React 基本上就是这两个中的一个现在对但是 React 我觉得他的问题是他已经定位成一个这种开源的项目了对但是 Vercel 他就可以把 Next.js 和他的 SaaS 绑定在一起然后赚钱这也就是为什么他就是他这套可以跑起来然后也招了很多 React core team 的人过去就我觉得这个还挺不一样的就是我就我觉得在大公司

非业务就像刚才孟迪也提到非业务部门最大的一个问题就是你很难把你的对于这个团队的资源投入和你的营收绑定在一起就比如说我做一个 feature 或者改进一个比如算法我就可以说我改进这个多了多少的营收对吧或者我降低了多少资源消耗或者带来多少新用户但是你 react 或者任何其他这种 tooling 你没有办法去把它对应到这种增长上所以

就很难我觉得我可以分享一下我在 Google 的一些经历像上一期节目其实我已经分享过 Python team 被裁的这个事情了然后如果有听众感兴趣可以再去听一下这个我觉得大家可能比较熟悉了然后可以分享一个另一个就是更和我个人经历贴近的故事然后 Google 内部它是有一套 Pipeline 的系统

就所谓 pipeline 大家可以简单理解成就是把一些 job 给一些任务给串起来我们要比如说按某个顺序或者某种依赖关系去执行然后像 Google 内部有一个这种相当于大家都在用的这种 pipeline 然后基本上很多 team 非常多 team 都在用然后但它当时

曾经缺一个很好的监控系统然后呢呃

我们组当时是负责 tooling 的然后我们对接的一个 team 正好在用这个 pipeline 然后我们就说我们可以他们有这个需求然后我们就说我们可以做一套这个系统本来是给这个 team 用的然后最后我们逐渐做逐渐做然后也吸引了一些就是其他部门的用户然后最后在我相当于我主要接手之后就把这个做特别大就相当于公司可能有几千个人都在用吧这种规模

然后有非常多 team 是依赖于这个监控系统因为它就功能非常强大如果你不用这个的话你可能有些很复杂的 pipeline 你是没有办法去监控的最后发生的事情就是我其实很想把这个做下去的但是我后来在的那个组虽然它也是一个算是做 tooling 的组但它对接的

它直接服务的一些组并不使用这个 Pipeline 的系统所以就相当于我在维护这样一套这个 Pipeline 监控但它实际上并不能直接对于我这个组产生收益那这个时候我老板就会

有一些疑问就说这个东西我们到底要不要维护但因为我很坚持因为我也对接很多用户然后他们也跟我直接提需求我在的时候我肯定是就是说 OK 我们要维护因为我们有这几千个用户我们不可能放着他不管然后之后我就换组了然后换组之后问题就来了对吧然后他们就我知道他们有很多讨论就这个东西要不要继续做下去然后再可能一年多

在我换组一年多两年之内然后这个是一直在做的然后甚至他们还重写过一次但是呢最后那个组遭遇了一些裁员就是 Google 也裁员过几次嘛然后最后我看到就是裁员之后他们就说 OK 这个东西我们可能就是没有资源再继续做了那我们就要把它去 turn down

所以最后尽管这个服务在当时 Google 内部是无可替代的然后每周可能有几千个过程师在用然后他们就把它下线了并且跟其他在英文的组说 OK 这个东西我们下线了然后有人问说那我们要用什么他们就说这个你可能要找一些其他方式大概反正就是没有替代品我觉得这就是一个非常典型的故事然后也让我很感慨我感觉

我明确知道这个工具它提供很多价值然后并且没有替代品但是因为它首先它很难直接产生营收然后其次是相当于它缺乏一个直接的 headcount 可能比 react 还更处境还更糟糕一些所以就你很难去 justify 说我们要放一个人去专门维护这个工具然后我觉得这里又有另外一个

另外一个反映出的问题就是大家往往更看重创造就是在大公司内往往更看重创造一个东西产生的价值比如说我做了一个新的 feature 不太多的用户对吧但很少或者说很难去评估我们把一个东西砍掉造成了损失因为这个东西没有人做然后就是做了也没有收益对吧你说你这个兔没了然后几千工程师的它的生产效率 productivity 受到损失那不会有人对此负责

并且维护这个东西保证这个生产效率不下降的人他也没有办法拿到相应的奖赏所以这种奖励机制就造成了你维护一个已有的工具是完全得不偿失的远远不如我把这个东西做完一个扔掉让我再做新的东西来的有就是对于个人来说有价值他可以甚至加薪他们组可以收到奖赏这种所以我觉得这种畸形的奖逞机制其实也

很大程度上导致了这种非业务部门的困境对是真的我觉得在一个公司内部的工具有上千的用户你可能说可能有更多吧真的是很大的影响他们不能就是如果没有人维护的话不能就扔在那不管就说我只放在那跑就当它是一个 Lexi 的工具但是我不下线

然后出了问题也没有人修谁爱修谁修这样的状况也是不能接受的吗对这个我其实是觉得我也很不理解的一点然后我觉得这个可能是 Google 特色我觉得可能在很多其他公司就会变成这种情况对吧有一个 legacy system 然后放在那不管也没有人接受但 Google 它就会

好像很在意这件事情就是如果你一个东西没有人维护他就会宁愿把它砍掉而不是把它放在那跑你觉得就像 Google 为什么以砍掉产品之名因为其实很多产品它就是比如说不论是人转走或者 reorg 怎么样它没有人没有一个很就是 active 的团队在维护它然后 Google 就宁愿把它砍掉而不是把它放在那就我

我不确定这是什么就是这个本质原因是什么但我的猜测是可能这就是 Google 从上古时期遗留下来的一个传统因为 Google 一开始是做搜索引擎起家的它从来包括后面广告它从来就没有一个直接面对 end user 的这种产品

换句话说 Google 的工程师或者它的整个管理系统它习惯于面对一个不是直接面对用户所以这就导致可能 Google 存在一种我称之为畸形的工程师文化就是以这种

比如说他们追求内部代码的统一性然后追求服务的效率但反而忽视了一些对于用户的价值这种东西所以你像不论是把公司内部一个有几千人用的系统给下线还是就是下线一些外部仍然有可能大几百万用户的产品这可能都是这种畸形的工程师文化的一个体现我觉得

但是 Meta 内部会有一些这样的挂掉的系统,但是可能它一部分还是好的,还有人在用。甚至会有这样的情况,它一半还是好的,它有五个页面,其中有两个还是好的,这两个页面还有人在用。

对然后呃我想 Google 可能是不能容忍这样的情况出现所以就如果没有没有一个系统没有对应的维护的团队的话就对没有维护他他就会直接下线掉对这也是真的是非常不认识文化不能容忍系统里坏掉的地方哈哈哈我觉得挺挺畸形的吧对然后说说回非业务文我觉得就是呃

就是我觉得首先营收难量化是一部分另一部分就是你对于公司效率的提升其实是更难量化对我觉得这个我体会到特别多因为当时我的旁边有一个人他做了一个工具然后他花了几周时间专门写了一个文档

去想怎么量化比如说他做了很多的一些不论是假设还是收集数据说原来有一个操作在没有这个工具的时候我们要花可能几分钟然后现在我们就花多少秒然后这个乘上我们现在使用这个工具的人数我们每个月给公司节省了多少时间他需要做一些非常精细的计算才能去证明这个东西是有价值的

就很难而不是说 OK 我增加多少个用户带多少营收这么简单直接就根本都不用去 justify 对吧我也想说一下我们部门是 SRESRE 也很就是与营收没有什么关系然后我们工作其实最重要的是安全这个安全其实也不是很好量化就是它坏的时候很容易量化你出了很多故障好的时候没法量化的你说我做了一个东西能

就是阻止一些故障比如说我说一个细节比如说我们在升级那个 binary 的时候我改一个东西它之前是直接下载 binary 然后去重启然后我现在把它改成了

我下载 Bunnery 到另一个地方然后我 Mode 覆盖到原来的那个地方我就阻止了一种可能的故障就是下载到一半断了的时候这个 Bunnery 就不可能再它就坏掉了就 Corrupt 了我这个修改可以阻止掉这个 Corrupt 的时间但是这个就很难说它其实你阻止的故障就很少能被别人看到这种东西就很难量化你说我这个到底阻止了多少故障呢但是我修改之前就是遇到过很多这种问题

因为什么网络问题下达到一半中断就是这么一个问题然后效率这是第一个第二个就是刚刚我们谈论的看不见的我觉得是同样重要的就是效率这个效率

说实话安全还是当它发生就是它不好的时候容易被看见它不好的时候不容易被看见这个效率是怎么样的都很难被看见这就导致一个问题就是每次安全就是刚刚我们说的是怎么提升效率对吧我们这个地方我们的工作里面很多人在降低效率你知道吗就是每当安全事故发生的时候就有人拿着放大镜在找我们这个

这个整个流程中到底在什么地方可以增加审批流程就是有些人会认为审批流程可以降低事故的发生所以每次故障都会加审批流程每次故障都会加审批流程就导致审批流程会越加越多就导致后来可能你做一个操作的时候你要找好多人审批就让这个操作变得效率非常非常低但是这个效率低其实

如果不是做这个操作的人因为去网上加流程的人基本上就不是做这个操作的人都是一些其他部门的人他们觉得加上这个东西可能会更安全但是他们不关心这个效率的问题对就会有这种问题还会降低效率但是也没有人对这个东西负责也是一个悖论说到效率这块的话我其实后来又写了另外一篇文章就是

讲的比较商业化,比较血腥一点主要的我的想法是这样子的就是碰到这种开发者效率的这种情况的话其实也不是所有的 team 都得不到支持也有得到支持的其实 react 早期发展过程中是得到了非常大的支持包括上到 CTO 都会直接下来支持支持这个团队去做很多事情

然后给很多资源然后包括要求其他 team 去配合他然后给很长的时间都可以什么都可以我总结来说就是说你们这些开发者工具框架新的变成语言这些团队的工作内容受到重视的时候他们的工作内容可以大致分成两类一类是必须有你这个东西

我们的产品的这些新功能才能实现你不做这个功能就不存在就支撑不了另一类就是说通过你们的这些工作可以让公司用更少的开发者去完成原本需要更多的人才能做的这个产品或者新功能那么这两者有个重要的共同点就是新就是你要有新的产品新的功能新的内容等等等等

显然在一个公司高速发展的时候这样的东西是很多的这样的需求是非常常见的但是当你的业务慢慢进入成熟的阶段的话对这类工作的需求就会减少当然有的公司会拓展它的业务线去打很多的新的市场但是那就是新的内容了那你原来这个业务可能就不需要这些东西了

所以其实我后来觉得你没有办法量化可能是一个表面上的原因很多难以量化的工作其实也很难也很得到很多人的投入比如说我很久以前在一家广告公司也不是直接做广告就是一个广告的技术平台就是去帮其他公司管理他们的广告投放的这么一家我就发现广告这个东西它这个才难以量化的

广告这个圈子里面有一句话叫做很不幸的是你的广告预算有一半是浪费的而且你永远也不知道是哪一半浪费所以它的效果是非常难量化而且比如说你的产品卖得好那是你的广告营销效果好呢还是说这个新产品本身就做得特别好特别受人欢迎呢对不对其实也很难量化但是

你一个产品要卖那这个公司就会投入巨量的资源大量的金钱去做广告然后就是说很多工程团队像你刚才也提到嘛就是说我们尝试各种方法来量化我们的工作产出对不对比如说我们给公司省了多少人手对吧省下这些人手

是不是折算成他们的工资啊那么是不是就比如说我原来这个要 30 个工程师现在只要 15 个了是不是省了 15 个工程师的支出但这种逻辑也是在一个成长期的业务

的这么一个语境下面是非常合理的因为你的业务在成长那你的人手就不够你需要人去你节省上来 15 个人对不对那你可以投入到其他项目去加速整个业务的发展但是如果你业务很成熟了那么

你这公司如果没有其他地方去让这 15 个人去干活那你省下这 15 个人的时间干嘛呢他们去摸鱼你提高了他们的幸福指数是不是但是这个公司在乎你幸不幸福吗其实不是特别在乎对不对那么你的总成本对吧和你的总产出是不是就没有变动了除非你公司把这 15 个人裁掉

那公司对于大科技公司来说他不会轻易裁人那裁人都是说大环境不好了才去裁人所以说甚至有一句话说 Google 给你开这么多薪水 Google 招这么多工程师不是因为 Google 需要这么多人干活而是因为 Google 能开这么多钱能招这么多人我招这么多人其他公司就招不到人了

甚至有个这个就是一个坊间的说法也不是说 Google 真的有这样的策略但是就是说其实实际上就是 Google 的招人的就是达到了这样的效果就是他其实在至少在某一些部门里面他的工程师其实是过饱和他其实不需要那么多工程师

其实咱们最近不是中美的科技巨头都裁员吗其实像传统行业我们也不说特别传统像那个 Lolingo 之前看了一个新闻说他们用 AI 去代替了很多内容团队的员工帮他们写一些

比如说他们不是教语言吗就一些题啊一些练习题啊原来是需要懂双语或者甚至多门语言的员工去写的嘛他们有 AI 了之后就裁掉了一大堆人然后只留下一帮人可能就把 AI 的内容审核一遍能过就行但是从我们打工人的角度来看你说我研发了一个工具提升了效率

然后公司就裁员了节省成本是不是有点太虚伶伶了我如果我不是原来的 DevTools Team 大家这么热心养育的给我一建议说你做加个某某功能我们能提高我们好多的工作效率对吧省我们好多时间如果这个省时间的结果是他们部门有人要被裁掉他们就不会来不会来跟我说这些了

公司就反而会给你提供更多资源以前你说你让公司裁掉十个人刚刚穆迪说的这个事就是导致别的团队裁员我们这个就是 SRE 里有一些有一些有一句话叫革自己的命就是有的时候你发明了一个东西然后本来五个人要完成一件事情现在两个人就可以了然后公司会把就是你自己的部门裁掉三个人嗯

其实我想说很多更传统一些行业的他们不是有工会啊什么的或者就是没有工会会在网上发生就是他们就反对这个行业里面还用新技术比如说出租车行业的人会反对 Uber 或者滴滴然后会反对无人驾驶车

那么其实是因为这些东西你说好不好它效率提不提升它其实是提升了效率对不对但是他们行业可能本身就饱和了那提升的效率就是最后的结果就是他们的整个的市场就他们整个行业就不需要那么多人那他们就会失业对所以他们就会联合起来去搞罢工这些事情就是美国可能多一点然后我

就不会带来他们不会给他们带来利益不会说我们的产量和销量增加了我们多赚钱了不会只会带来财源我觉得我后来就想说那科技行业的这些工程师比如说汽车行业的工程师就会做那样的事情就会反对新技术我们这些就是做互联网的这些科技行业工程师我们特别喜欢去搞带来效率提升的新工具我觉得可能是不是因为这个行业

高速发展了太多太多年了所以而且大家都预期自己会继续高速发展会站在浪潮的尖端那是不是就是不需要担心这个事情我只要效率不停的提高我不停的有新的活要做我不停的赚更多的钱所以当然也有点跟我原来刚才提到说科技行业其实不喜欢裁员

也是有这个原因吧因为这个行业高一直高速发展嘛那我不需要裁员所以科技行业裁员就不是像其他行业一样说我现在效率提升了我就裁员部分人都比较少这样

这我觉得有对我非常同意有你说的这种大家的思维习惯的问题就因为科技行业的人习惯了高速增长所以就是提升效率在大家看来是发明新工具提升效率在大家看来是一件天经地义的事情但我觉得还有一点和其他传统行业不一样就是因为互联网或者说 IT 它是不依赖于某种实体的换句话说它的复杂你可以无限的创造复杂性

就我们可以看到比如说你说你改进一个汽车的效率对吧它汽车实体总是在这里但其实你再怎么改进它总得有比如说四个轮子有一个发动机对吧你没有办法做出你没有办法再重新创造一个比如说一个隐形汽车我们就说

而你如果没有办法重新创造这些新东西它的复杂性其实是不会爆炸性增长的而且它的相于坑位也不会突然增多它只会有一个原本的但是你在你如果是代码因为它没有一个实体比如说在 react 之前然后或者在 angular js 之前对吧大家都是很传统的写 html js 然后现在突然有了那个 single page sra 这样子

然后有了 Angler 有了 React 和 Vue 大家不断在挖新坑然后这些新坑它又带来了工具链的需求然后这些工具链直接交互或者说工具链原本工具链性能有问题然后大家又发现新的需求需要写新的工具去代替原来的其实它的复杂性是在无线爆炸无线就是永远是增长的所以我觉得

这个可能是科技行业一个不同的地方就是它永远因为它的复杂性永远在指数级增长所以永远有新的机会新的需求我是这么觉得我觉得前端的复杂性是不是快看到头了真的吗就现在看来 react 是一统天下但是未来说不定又会有新东西也没有一统天下也有像 Viu 也有很大的市场氛围 Angela 也有

也有不少人还在用甚至有的人就说我用别的他们甚至用其他的编程员直接来写钱的不用 JS 或者 TypeSpark 也有但是

但是我为什么觉得前段是不是发展到头了因为 react team 这么难过是不是没有什么新活可以搞了呢但是我觉得 react team 的困境说回来更多的是因为 Facebook 或者 Meta 它已经在 Meta 内部已经稳定了对吧你像 Meta 不可能再用一个新框架替代 react 所以它像我们之前说的它已经没有更多的新需求了它可能 VR 的支持是一个新需求这个方向可能会有一些但是原本的这些它就很稳定了所以

就对确实确实像比如说 Next.js 这种东西其实 Facebook 内部老早就有一个当然不是用那套技术实现但是有一个相对比较类似的东西已经解决了很多开发商的评论很多开发商的痛点已经有了所以就不会不怎么有动力说我们也搞一个像 Next.js 这种东西或者我们直接去用 Next.js 不太有这些东西确实如此

而且我知道其他的一些就不点评前端的发展潮流了但确实也有看到一些新的东西

换句话说对我觉得就是我根据我们之前聊的其实差不多可以总结出一个大公司内部非业务部门困境的答案了就是因为大公司他没有办法去快速的迭代更新他的技术站他的技术站总得是比如说趋于统一和稳定因为大公司喜欢这样而这就导致公司内部的这种非业务部门它的空间实际上是越来越小的

不论是他创造新技术然后也包括他提升的效率其实并不能直接带来公司运营成本的节省因为你没有办法裁员总之就是他空间越来越小所以他就会越来越困难就可能是这个问题的答案我觉得所以也不能怪大家去追逐这个风口是不是现在大家一窝蜂的搞 AI 包括我自己

去一些创业公司然后你可以做一些新的东西对创业公司肯定有新的东西要做然后如果一个工程师特别喜欢做 infra 这块的东西的话可能你去追求一些风口也挺好的所以我之前也聊到做原来做 infra 的朋友就说你们就去搞 AI 就是了不要想那些老旧的东西

全部去搞 AI 吧我真的觉得就是得去找一个风口有风口就 infra team 就有活干现在 AI 这块的 infra 也一大堆嘛

就真的是从数据库最开始火一批限量数据库其他的数据库也有然后有文件系统文件系统这么老的东西都有好多个公司做然后各种包括什么 influencing 包括什么当然更接近 AI 产品的就不说了就非常底层的一些东西只要能跟 AI 站上边甚至硬件

大家跟 AI 展场别人就 VC 愿意投就有活可以干对我知道现在网络在 AI 方面也挺火的就是 AI 训练需要非常高带宽高速的网络对我觉得开源世界因为没有大公司的这种限制你就可以让复杂性无限复杂度无限的增长就会大家总有新的空间去做新的东西对就回到我们之前说的

OK 那我觉得就是我们要不要再说回来总结一下就是比如说假设一个听众对吧他现在是在大公司的非业务部门那么他可以比如说怎么做呢有没有什么建议如果可以的话就去去找新的活干对吧封口我们虽然对吧作为工程师可能觉得

有些公司的决策不可理喻或者说觉得对吧为什么非得要搞一个新的东西呢但是规律就在这我们在能改变它之前可能就是顺应这个规律去搞点新的东西做然后或者说能蹭一些风口

就是比较会过得好一点如果你确实很想做 infra 这一块的话当然就是说如果你只是想好好做技术你无所谓说我做 infra 还做产品那做产品也可以了是去找公司比较重视的产品去做也是 ok 的好当然另一个就是说可能怎么说呢你如果能跟对吧提高自己的这个

沟通能力软实力对对不对让这个上层领导特别支持你呃做你的项目那也是非常理想对可以呃就是让让其他人看到做的事情的价值对吧它肯定是有价值的只不过这个价值非常难以被被看到如果可以的话可以

就是让自己做的事情的价值也被别人看到那我觉得如果你有这种能力的话你不如跳出去对去拉风头你有这种能力你可以在公司内部先试一试是说你你做东西能不能让其他就是非技术部门的人觉得你做的特别棒感觉你做了很大贡献你没有直接在做产品但是他们却觉得你做了很大贡献

我觉得你如果你真的可以的话要自己做 startup 也不错对如果但是如果发现自己每天都在做做这种事情每天都在做 PPT 想办法让别人看到自己做的事情的话也基本上是时候换一个工作对技术人可能还是想做技术吧对就是说到可能如果两种你既能做技术又会做 PPT

是挺好的不要让人觉得你只会做 PVT 这样就只能转岗了只能做产品经理了对也不能不排除你想做产品经理对也不能说实话也不能只做技术这样的话就是虽然这样很快的但是其实很难找到一个非常非常适合只做技术的岗位大部分技术不是大部分岗位都是需要一下就是做 PVT 的这种技能的

OK 那我觉得就是关于就是主要的大公司非业务跟困境我们基本上也聊得差不多了然后我们最后也得出了一个看似还比较合理的答案吧对然后希望这期节目也是能就是给听众们带来一些价值那我们按照惯例最后会有一个推荐环节对不知道你有没有什么

以前自己搞什么 BPSBSP 这种感觉自己部署一个东西很麻烦最近发现 Cloudflare 特别好用然后又不要钱对你听了我们前段时间节目吗你是听了我们节目没有听对然后另外的话我就是觉得

怎么说呢就是我最近看了因为我自己现在在做 a 码然后我觉得那个那个啊卡帕西的视频他讲的真的就是也不不光光是 a 码就是呃反正就是对整个技术不管甚至对于你职业上的发展都挺呃至少对我来说挺有启发的我知道他有一个从零构建 llm 系列那个对就是

总的来说还是就是说其实很多东西没有大家想象那么难特别大家能做工程师的话肯定都是挺聪明的人其实都可以去看一看尝试一下对自己训练给 LM 看一下虽然肯定效果会很差但是你可能会觉得说你做出来这个东西其实你只要有足够的 CPU 去训练然后足够的数据其实可能就是一个很好的东西

OK 理解那信涛那边有没有什么要推荐的我推荐一本最近正在看的书 The Manager's Path 不知道你们有没有看过没有可以介绍一下这个书您看起来是教你怎么做 manager 的但实际上它是教你怎么工作的它会介绍第一章怎么被 manage

然后后面会讲会讲怎么 mentor 然后讲怎么处理工作中的一些情况还挺契合今天的主题的讲的干货非常多就是我发现他讲的那些很多情况其实我也遇到过对就推荐一下这本书有没有什么比如说一个例子你可以分享一下就是从中学到的

有一个例子啊就是讲一个反例吧就是他他讲那个工作中有一种有一种人叫 Alpha Jake 就是他可能承担了足以大部分的工作的可能不跟同事打招呼就把别人的工作重新做一遍能力非常强然后会非常啊怎么说呢他不允许别人挑战自己的决定确实能力比较强然后他讲了怎么呃

他讲的是作为一个 manager 怎么去和这样的人工作就是首先你要让他当 mentor 然后不能直接让他当 manager 这种人是不适合当 manager 然后可能他会发现自己的问题或者什么就解决这样的情况然后我读这个的时候我就在想自己是不是也是这种人我发现自己有一些这样的情况之前是一个很好的反思挺好

OK 我最后再推荐一篇文章我不确定之前有没有推荐过因为前段时间在推特上又看见了所以我想着再推荐一下就是那个叫 Beinglu 翻译成中文就是成为浇水那篇文章是一个非常经典的讲在公司里工作

如何避免一种坑的文章简单来讲这个文章就是说你需要去识别某一些有一类工作他称之为 glue work 就是浇水工作这类工作比如说你可能去帮别人 set up 一些 meeting 然后去做一些这种非技术性和你的项目不直接相关

但是又很需要的工作就是这种东西对于初级工程师他文章的结论就是这种东西不适合这种工作不适合初级工程师来做然后如果你是一个老板的话你应该避免初级工程师去做这种工作然后如果你是一个初级工程师你应该去避免自己做这种工作因为他对于你的成长是不利的我觉得这篇文章反正我是推荐每个人都读的因为

就我觉得不论你是初级工程师还是你是有一定工作经验的人因为你可能要 mentor 团队里其他人嘛都是都是很需要的对非常好我也看了那篇文章确实特别特别好特别特别好对呃而且如果高级工程师你读这篇文章的话可以如果你没有做过这些如果你一点都没有做过其实你应该做一点对同意其实就是这些工作就是应该团队里的 TL 啊或者高级工程师甚至老板去承担对嗯

好我们今天推荐的东西都是和今天的主题相关好的好的好那我们最后就再次感谢梦迪来做客我们的节目然后谢谢梦迪谢谢大家谢谢听众我们就下期拜拜拜拜拜拜