如何因你而不同

前言

春节前写了一篇文章《我对不同阶段前端工程师的额外要求》。在掘金上发表以后，争议很大，喷的人很多，弄的我也很气，本来是想写一篇《如何看待当代掘金喷子》。想想也不应该这样，有争议，说明一定存在一些问题，还是应该要先讨论争议本身，于是有了这篇。

文章中争议最大的是对于P7同学的“因你而不同”的要求，很多人觉得太 PUA 了。能理解质疑，但反对无脑喷、反对阴阳怪气、反对预设立场想批判我一番的任何人。

所以关于这点，我再写一些详细的阐述，跟真心有疑问的同学做一些分享，一起交流。

什么是因你而不同

先讲一个小故事。
早在 8 年前，我发现了一个色彩网站，叫中国传统颜色 。上面的颜色确实都挺好看。

现在可能很多人都知道这个网站了。但当时我就发现了一个它颜色好看的小秘密。网页的背景其实有一层底纹背景，使得颜色透出一种略带哑光的质感，而不是简单的纯色。尤其是在淡色系的颜色下，美观性相差很大。所以很多人看网站的颜色挺好看，而自己拿去配色却不一定有这样的效果。

随便拿几个淡色颜色对比一下，左边是有底纹的，右边是无底纹的

文章可能图片较小，差异性不大，样本也较小，可自行打开网站，zhongguose.com/ 打开 devtools 尝试体验。

不同的人可能审美不一样，但我个人确实觉得带有底纹让这个网站更出彩了。仅仅这一行代码，让整个网站摆脱了单调的纯色，增加了一抹特色。

所以回到什么是“因你而不同”？我心中的粗糙定义是：“因为有了这个人，团队有了些不一样的特色”。就像这个底纹一样，倒不是一定是费了多大的努力，也不是一定是别人做不到的。但此时此刻，确实就是你做了，确实就是给团队带来不一样的特色了。我觉得就是因你而不同。

当然，也有很多就是靠实实在在费了很多努力，花了很多时间才做出亮点来，那当然也是“因你而不同”。这样的不同也可能更有一些“壁垒”。

但无论是靠创新、靠努力、靠其他的手段与方法，这些都是“路径”，给团队增彩才是目标。 这一节我们主要讨论的是目标，而不是路径。

当然也有同学有疑问，目标如何评判？就比如刚刚的网站，不同的人审美并不相同，有的人觉得加了底纹更好看，有的人觉得是画蛇添足。对于这个网站，最终的评判自然是交给用户。如果要量化，就是严格控制变量，加了底纹以后，判断访问用户是否更多，用户留存时间是否更长。

在实际的工作中，不同的事情自然有不同的评判标准。实际工作中，很多事情也没法很好的 AB。但同样的，在这一小节，我们只是谈论了目标是什么，还没谈到如何评判，后面我们会再详细谈到。

但既然是目标，有两个特点是需要强调的。其一是，不同的环境下有不同的目标；其二是，目标是阶段性的。

举个例子：
假设某同学 A，对 React 框架掌握的特别高深，把他放到一个还不怎么会 React 的技术团队，过程中辅助团队同学一起学习，过了一段时间，整个团队对 React 都非常熟悉深入了。那这妥妥因他而不同了。

但假设把他放到 React 作者团队呢？只是靠自己对 React 的熟悉与了解，那肯定不够了，大家都很了解很深入。有你没你只是是人力资源上的问题。这个时候就很难说因他而不同了。

所以「因你而不同」是动态的、是根据环境变化的。当然也不是说这个人就不应该放 React 作者团队，只是从刚刚那一个方面去看，他并没有出彩之处，但说不定他有更多其他的牛逼之处。

其他领域也是一样，Node、低码、互动，或者团队管理方面等等。所以资深及以上的岗位，肯定会考察某个领域的深度。一个没有专业领域的人，很难通过资深岗面试，因为对现有的团队很难有增量。

那是不是说 因你而不同 === 核心竞争力？我觉得也不全是。有核心竞争力的人当然能在这个核心取得更多突出的成就。但今天追求的还不是这个，因你而不同，不是考量一个相对持久的能力，而是追求一个阶段内的贡献。

再比如说：
还是刚刚的某同学A，他真的加入了 React 作者团队，然后他深刻的意识到了 react hooks 对开发者编写心智的负担。他潜心研究，终于重新设计了一套能力，支持了 hooks 不需要传递依赖项，可以在条件语句中执行（纯粹假设，先不考虑实际上是不是真的可行，暂时也不考虑特意用做生命周期钩子的场景）。并且性能与安全性都没有任何损失，也没有改变 React 的其他编程范式。那 React 妥妥又因他而不同了。

也许他不一定比别的人聪明或者技术强，可能仅仅只是他铁了心想解决这个问题并持续的投入，最终确确实实解决了 React 框架的一个痛点并获得了开发者的喜爱，这就是因他而不同。

但他能因为这个事就吃一辈子结果吗？当然不可能，React 可能还会继续迭代演进，在未来的版本，可能会有因他的亮点，也可能没有。因此“因你而不同”是具有阶段性的，考量的是一个阶段内的贡献。

除了技术上的事情也有非技术上的，比如团队氛围建设、影响力建设等等。

“让团队有了不一样的特色”可能说的还是比较感性，让人感觉能理解又难体会。尤其是很难区分自己的本职工作与额外工作。一定要区分的话，我觉得本职工作是保持团队的惯性，而“因你而不同”是给团队带来加速度。

可以把团队理解成一辆持续行驶的列车，本职工作是维持列车安全的匀速前进，而“因你而不同”是给列车再提速。提速的方式有很多，可以是凭借自己的高超的技术再踩点油门；也可以想办法重新设计发动机，增加效能比；也可以重新设计列车的形状降低风阻，等等。

所以总结来说，我对“因你而不同”的详细描述是：因你做的一些事情，在某段时间内，为团队创造了额外增量或带来了新的亮点。

如果关于“因你而不同”还有补充建议，欢迎评论区友善交流。

为什么 P7 需要“因你而不同”

在之前那篇文章中，我对 5 的额外要求是“小镇做题家”，6 的额外要求是“科学做事者”，这些描述都是聚焦其自身。从第一小节的阐述我们明白，“因你而不同”，是关乎团队的。

所以「为什么 P7 需要“因你而不同”」 这个问题也可以转化成「为什么 P7 需要考虑团队的额外增量？」

原因很简单，P7 同学就是靠整个团队养着的，自然也应该更好的回馈团队。

在非大厂，大部分的 P7 已经是主管了，一线同学辛辛苦苦干活创造的结果自然也是主管的结果。那怎么可能不考虑团队的事情？怎么可能不考虑给团队创造更多的结果，给下属争取更多的机会呢？

当然也有不少 P7 仍旧是一线同学，但这些同学往往也是承担团队中较为困难，具有挑战性的事情，做成了也容易拿结果。那这些事情是哪里来的呢？不还是团队给予的吗？哪里不是一个萝卜一个坑呢？但哪有那么多坑呢？现在问题来了，坑是有限的，当你进去的时候，就自然会有人进不去。

如果你是没进去的那根萝卜，但你自己挖了一个好坑自己进去了，甚至还能多挖几个给别人。那你妥妥最牛逼，团队因你大大的不同。如果你是进去的那根萝卜，那你能不能想办法让坑大一点，让别的小萝卜也能进来？

团队有个坑，自己进去了占着，别人也进不来，自己也不愿意出去。然后写一堆屎山代码，把这个坑固化成只有自己屁股能蹲下去的屁样。那真的是王德发。

所以总结一下：如果你是萝卜领导，你就应该负责挖坑；如果你是已经进坑的萝卜，至少要想办法扩大坑；如果你是没坑的萝卜，努力给自己挖个坑。没坑的萝卜肯定会死的。

大家都不挖，都不给地松松土，那就只能相互眼睁睁看着，然后烂在地里，有坑没坑只是早死晚死而已。

“因你而不同”具体做什么

在之前文章中，我也已经提到过一些：

团队今年因为你，技术氛围变得更好了，历史债务变的更少了，同事成长更快了，研发效能变的更高了，创新项目越来越多了，用户体验越来越好了，业务成功可能性越来越大了

其实我们能做的方向有很多，一个团队一定有现在这个团队存在的问题，需要现在的人去解决。以前端技术的一些发展历程举例：

业务上的问题也是如此，BFF层、低码、营销搭建、混合开发等等。

举这些例子不是说 P7 同学需要达到这样的水平，不可能要求所有的 P7 都能整这么牛逼的开源框架或工具，反正我是达不到的。我只是想说，每个阶段肯定有这个阶段团队遇到的一些问题。更多的是要求我们能去发现问题，有去解决问题的勇气与毅力。

可能是造了一些新工具，可能只是引入了一些新工具，技术上或难或易并非是最重要的。最重要的是，能解决当下的团队问题，同时不堵塞未来几年的团队发展。

具体一定要能做什么，肯定是因为团队而异的。大型初创团队可能是做基建；业务技术团队可能做领域解决方案；极速扩张的团队可能要打造影响力；发展多年技术老旧的团队可能要做技术演进等等。

当然，确实，很多公司的前端已经进入了深水区，其他岗位可能也进入了深水区。10年前互联网起飞时，很多事情很容易做，也造就了很多成长很快的互联网人。

亦或者团队确实很成熟了，各方面建设都差不多了，业务也不是飞速发展了。好坑越来越少，新坑越来越难挖。

这些是客观现实，我们能做的只有两件事。要么在这个客观现实下，继续努力去发现别人发现不了的问题，去解决别人不敢解决的问题。要么换一个没那么深水区的业务、公司甚至职业方向。

但话说回来，全新的领域，收益越高，但门槛跟风险可能也越高。AI 大概率是下一个风口，你有能力去这样的公司与业务吗？你有能力的话，你又敢去那些初创团队吗？

10年前的互联网人确实踩到了一波风口，但也承担了很多风险。当年在他们眼前可能有更多当时更优的选择，他们或许因为运气、或许因为远见、或许只是因为固执。所以成功也不能只是片面的看。

说了这么多，想表达的是，要辩证看待事物发展。更多的是要锻炼自己发现问题解决问题的能力，而不是焦虑于无事可做，埋怨于生不逢时，归咎于他人尸位素餐。

如何科学的做评判

如果是某个技术问题的攻坚者，本来就是把难得的有技术挑战的事情交给你了，你自然觉得自己牛逼了，自己解决了困难的事情。但是换一个寻常 P7，甚至是换一个经验丰富些的 P6，他真的就一定做不出来吗？

之前文章最受人诟病的可能就是这句话。很多网友因此来质疑我，我底气很硬，因为我主管是把有技术挑战的事情交给了当年还是 P6 的我，我是被比较的那个 6，也是因此升的 7。等我到 7 后，几乎没有什么是主管“交”给我的事情，自己成为了挖坑者。当然主管的鼓励、支持跟一些关键方向判断是至关重要的。

但是不可否认的是，很多事情确实没那么好比较。文章在内网语雀中有个同事也有一些质疑或者说建议（素质比掘金一些喷子们高的不知道哪里去）。

同事说的很对，真实世界不能做 AB，很难评估事情是因为一个人而不一样。评判的标准跟角度又不一样，评价不一定公平。

她的话，也是我再写一篇文章的关键动力。

关于如何科学衡量，我仔细想来，其实分两个方面。一个是评判者的视角，要怎么评判别人；第二是被评判者的视角，如何让自己的事情尽量被科学的评判。

关于评判者，我目前还没有能力说太多笃定的观点。只能说我自己作为一个评判者时，我会怎么做。写完我自己反思一下，觉得自己现在做也不够好，但我觉得应该要这么去做：

第一，要有足够的视野。评判就需要比较，比较就需要了解。如果自己都不了解别的团队在做什么，效果怎么样，如何评判自己同学做的事情是否比别的团队的同学优秀？自己同学整了一年性能优化，各种打包优化、缓存策略、异步控制，最后实现了首屏2秒打开。然后别的相似竞品团队是半秒，大家起步也都一样，如何说自己同学做的好？

当然里面可能还有很多客观细节。我们服务端的接口性能是怎么样的，我们的人员投入是怎么样的等等。

所以第二，对自己团队了解要足够深入。自己团队同学是怎么做的，如何做的，技术背景与业务背景是怎么样的。真实情况特别复杂，仍旧需要综合各种因素去考量。但事情要尽量做在前面。

所以第三，过程要持续跟踪。别等同学都整完了，一年到头了，再去做评判。过程如果自己发现不对，就应该尽早干预，与被评判者及时对焦。综合分析，设想出我们能做到的，能努力做到的，能奇技淫巧做到的，能另辟蹊径做到的。

还有一点最重要，就是要教会被评判者该如何被科学评判。

评判你的主管跟合作方一定会有他们的视角，可能跟自己的视角不一样，可能他们的高度不一样。但无论如何，那是他的决定，作为被评判者，往往没有权利或能力去改变与干预。我们能做的是，尽量把自己做的事情充分的表达，最终尊重他人的评判。

如何充分的表达，我觉得关键是两点，其实在之前文章 P6-科学做事者 中，也有提到：

第一，一定要有数据意识。有的同学只做事，不分析，不给量化结论，只给感性结果，这个是大忌。感性的结果在评判者那边自然也只能感性的评判，感性的评判在矛盾对立时就会演化成争吵。你说你做了一个搭建能力，做的非常好，代码写的非常漂亮，业务非常喜欢。但却拿不出一个数据，到底搭建了多少页面，每个页面搭建耗时多少，建设/复用了多少组件。就说自己做的好，这如何评判呢？

第二，一定要做好过程记录。很多事情确实不太好量化，或者确实没到周期能去统计量化的结果。比如到打绩效了，系统才刚刚上线没多久，数据还不足够支撑；或者突然因不可抗力，不是因为自身问题，某块业务突然黄了，就是没有任何数据。这个时候只能看过程。

但很多同学过程也没做好，要啥啥没有，只有一堆系统代码。这让人怎么去评判呢？评判代码写的好看不好看吗？

把做事前的调研分析、把自己的系统设计、把过程的核心问题与解决方案等等做好总结。通过月报、规划会、述职会等渠道晒出自己的过程。考虑的是否周全？方案是否当下最优？是否有创新设计？问题是否具有挑战性？是否有领域洞见？上下游合作是否顺利？即使这些事情从业务结果上没对团队带来增量，但过程的想法、自己的经验总结，我相信对团队一定也会有额外的帮助。因此我相信，一个不瞎的主管能够区分是否有“因你而不同”的地方。

如果你觉得这样了，你的主管跟合作方还是瞎，可以努力再做一些对焦。如果真的很难取得一致观点，你觉得他们就是瞎，建议换工作。

最后再说两句

一个团队，无论什么层级，其实最忌讳的是满满负能量的人，不要把事情总往不好的方向去想。如果有质疑，可以提出观点，一起讨论。而不是预设观点，以最坏的恶意去揣摩他人。

我曾经写过一篇文章《如何做一场高质量的分享》，开头便讲到：分享的本意就是总结并传播知识，分享的核心是利他。扪心自问，我一直在践行这个观点。很多人加我微信跟我交流技术或经验，我也几乎没有任何保留。无论对方是什么人，提了什么技术问题，也几乎都会回答。

努力做一个对社会、对他人有帮助的人，这是我的人生信条之一。