侠以代码犯禁，大厂也能修真！不求人不卷也不躺

大厂staff讲讲自在不求人、不卷也不躺、不被商业秩序异化、技术修真型的职场侠客之道！

侠客之道：一个技术人的职场生存实践

论坛有很多讨论职场生存状态的帖子，主要观点有卷有躺也有看开的。

楼主则试图既要在商业秩序下创造价值、有成就与影响力并得到职级带来的高收入，又不接受职场价值观的规训，按自己舒服的方法行事。

楼主所在的领域是做大规模分布式数据库/query engine/data lake的综合体，非开源也不使用开源，所有子系统加起来可能有将近千万行代码，部署量在10M计算单元级别，有专门的运维团队所以oncall基于自愿且强度不大。系统在公司里有相当重要的地位，大组里高职级的也很多，这是大概的背景。

技术立身，不吃项目压力。以高爆发获取信任，但不当持续输出的老黄牛。免疫promo文化

要做到这一点，核心在于系统代码的复杂度及其所涉及的领域知识的深度与广度能够使软件开发的那些容易使人异化的管理手段失效，也就是堆人力无用、无法有效预估成本、而团队里或是市场上招来的绝大多数人给压力也出不了成果。

在这个背景下，领域知识是不是到位、对整个系统有没有比较透彻的理解，可能决定你做一个项目是花三个小时、三天还是三个星期（然后再断断续续花三个月去解决上线后出的各种问题）。一个小的项目，可能只需要添加100行代码，领域专家列出步骤123然后让人contribute开发，但是这几步所涉及的底层原理以及没有讲明的只是按步骤做就能避开的各种坑，要弄清楚却可能要花超过按步骤写代码100倍的时间。

这就形成了一个很有意思的负反馈机制：越是卷项目追求产出，背的技术债就越多越做不动。特别是如果通过取巧卷横向项目快速升到了比较高的职级，然后想要推动一些有影响力的涉及到整个系统的项目，很容易就会被系统内几座大山例如内核、优化器、分布式框架、存储引擎等等10多年的屎山代码和和DB这门学科60多年积攒下来的各种领域知识压倒，项目推不动到处求爷爷告奶奶。

但如果你真想要攻克大型系统内的这些大山，去掌握内核、优化器等等数百万行的核心代码，对整个系统有全面的成体系的理解，这时候另一个有趣的负反馈来了：做这些事没有impact！吃透内核吃透分布式框架等等这些东西要想有所小成，花的时间以数年计，但其本身不能帮你提升绩效或升职。升职走的是商业价值逻辑。

其实这一套双向负反馈机制对不少刚入行的人来说可能是噩梦，但另一方面它也塑造了一种可以与导致卷与毒的商业逻辑相抗衡的秩序（当然前提是你这个领域足够重要，楼主所在的大厂DB部门算是一个例子）。在这种秩序下面你想成为核心领域的TL，那得先在心态上禅定，牺牲一些短期利益，才能在技术成型后做到厚积薄发。而大部分核心领域的TL也正是这么过来的，才可以形成自在不卷的团队文化共识。

分享知识，助人但不求credit

对于这一点，地里有很多举反面例子的帖子，什么抢credit学会徒弟饿死师傅之类的。但对于楼主所在的这种复杂系统组而言，其实抢credit是很难的，崇山峻岭压着，你刚有一点小产出就把向导丢了那之后就不好混了。而且由于上面所说的双向负反馈机制，很多时候助人可以双赢。比如说一个项目，预期有不少impact但是脏活累活也有不少，然后系统里面某块不懂或者踩了坑出不来，对于很多人来说已经很struggle了，你还要他去深挖底层那真是要了命了。这个时候楼主去做做knowledge sharing，讲讲底层原理再给点实现方面的指导，那就是技术影响力，虽然不求credit但很多时候也能挂名。

而且无条件助人更重要的作用是一种自我实现与超越性价值，并且现实上确实也会积累“基层影响力“。楼主标题说“技术修真型的侠客之道”，这里最重要的一点是要能维持一个比较稳定的价值内核，相信自己是有价值的并很少在职场环境下有情绪波动，从而可以坚持按自己的方式做事情。

当职场外宾，不求人

这里的“不求人”不是说蒙头做自己的事情不和别人打交道。要走技术路线，技术影响力非常重要，也就是你说啥或者做啥技术决策，别人得觉得有道理可以服你。在DB/query engine这样的领域，因为有几十年的领域知识包袱以及数百万行代码的系统复杂度包袱，水平上去了其实很容易有“降维打击”效果。另一方面，与人合作时有所求也是一种建立关系赋予别人价值感的方式，甚至给小弟安排工作也会用一种“这件事就拜托你了“的态度。这种态度甚至是一种传承，比如很多好的PhD导师对他们的学生也是这样。

那这里说“不求人”指什么呢？其实在国人大部分的语境中（可能国外文化也是如此），求人指的是“求贵人”，也就是一种机会心态，期望自己机缘巧合或者通过表现得更“努力”或者是提供情绪价值来得到上位者的额外赏识。为了这份赏识，很多时候你就得压制或者扭曲自己的真实需求，甚至欺骗自己，因为你的价值依赖于少数人的喜好或评价而不是基于技术影响力或个人魅力这种具有普适性的东西。而且这里求的可能不是生物“人”，也可以是广义的职场价值体系、升职标准。当然，也不少人可以分得开，往上爬的时候是一套心态，但上位了之后可以洗白调整过来。

楼主做职场外宾的方法就是完全不看什么tech ladder的那些标准，而只是按自己喜欢的方法做事情，而做这些事情产生的价值大概一部分align了公司的要求，但也够用了。楼主写staff升职doc的时候只花了一晚上时间，写doc的时候才去看了一下L6的标准是哪些，然后align了一下所写的内容。

技术立身的底层逻辑

一方面是很多国人在潜意识中受到深刻影响的侠文化，所谓仗剑江湖、侠以武犯禁；另一方面是需求层次理论。

人在职场爬梯稍微到达一些层次后，必然会有更强烈的寻求安全与尊重、自我实现、甚至是利他（altruism）的超越性需求。这些高级需求如果建立在互联网商业价值与秩序的地基上，其实是不稳定不自洽，很容易被打击甚至摧毁的（例如被裁员、政治斗争失败、项目reorg、“贵人”离开或失宠，等等）。然后很多人会转向虚无主义，消极的比如躺平或者“工作就是日结挣钱”，积极的则比如追求财务自由从而将安全尊重、自我实现等个人最根本的需求与职场的价值、秩序进行彻底的切割。

而楼主所践行的，是以纯粹的技术能力去融合几种价值，但以心态上的平静与自由以及自我实现为核心追求。虽然要做到这样并不容易也不一定能永远持续，但我觉得地里很多人其实非常想要反抗职场价值观与规训给人带来的异化，这篇帖子可能可以提供一个视角和一些理论。

补充内容

有个回帖提出了一些很好的质疑，我置顶了对疑问的回复作为对原帖所缺失一些细节的补充。

关于第一点，主贴篇幅所限可能让你有一些误解，认为我举的例子是说存在一些“点”我懂别人不懂所以可以套利。但楼主主帖所说的“双向负反馈”其实就是在强调核心竞争力并不在于某些“难点”，而是数百万行核心代码所构成的整个知识体系。很多人在DB组工作多年，也只能做到掌握一些点状的知识，知道系统里面孤立的一些地方有哪些坑该怎么做，但孤立的技术点其实是很容易学习的。楼主在主帖里说的厚积薄发，就是你在积累到一定程度后能对整个系统形成一套方法论，在别人眼里系统处处是难点，但是你可以在已有知识的基础上去快速阅读源码、推导逻辑、或者做一些实验来迅速掌握自己本来不知道的地方。那么在别人眼里你好像什么都懂，对于一个非常庞大的、积累十多年数千人contribute代码的系统，问什么问题都能迅速给出答案。但实际上，我只是知道怎么去快速的problem solving找到答案，但这仍然需要基于对系统有大量的知识储备。能做到这一点的人其实很少，并不是能公式化培养出来的，要不然我也不会说“侠道”。很多大厂L6、L7，你可以说他们有business value，这一生如履薄冰在自己的role上兢兢业业。但是要做到对一个庞大而复杂的系统融汇贯通，入职三五年内摸不到门道，那很有可能一辈子也不会有太大长进。

其实你所说的“生存的底线”也反映出了我们mindset的不同。我这个帖子的核心观点或者说想种下的一颗种子，就是人可以不焦虑、不被push、不被驯化/异化，却仍然能够得到不错的产出与结果。人这一生在每个阶段都会受到环境的规训，而职场环境下就是商业价值共识所衍生的tech level这一套behavior标准。我主帖已经说了，有些人是被驯服，去接受、拥抱这一套东西，最后成为体系的一部分，会反感不合这套规矩的做法并试图用体系内的价值观道德观以及各种黑话去压制“异类”；而也有很大一批人是摆烂躺平。那有没有第三条路？我写的这个帖子就是抛砖引玉。再举个例子，楼主读PhD的时候曾经连续两年多因为各种按自己想法做事疯狂miss投稿deadline，导师每次都急得抓耳挠腮，但这不影响他说我是他的best student之一。这种情况多数人而言可能早就quit或者被开了吧，但楼主还就是能最后得到不错的结果。当然你不要又断言楼主导师是什么水货，他现在在CMU cs 是full processor，在业界也颇有知名度。

关于“抢credit"的部分，主要是地里讨论这个比较多所以顺便提一下。其实我们组由于技术复杂性比较top-down，所以在各个level几乎都不存在抢credit。争scope的情况是有一些的，但多数发生在org level的横向项目，而且我们系统算是org的招牌所以话语权比较大。

就技术的难度和长期价值而言，我只能说你大概没在DB领域工作过也没深入接触过DB底层。业界很多人看个DDIA，稍微读一点Postgres或者MySQL源码就觉得总算修炼了一把技术了。但你就算通读DDIA都不一定能过DB PhD Qual。而复杂DB系统上的开发想要做的好，领域知识、快速读源码能力、对复杂结构的抽象能力、逻辑的严谨性、对底层的性能理解、代码质量，缺一不可。这里的大部分技能都是transferable的，而内核与优化器方面的领域知识更是全行业通用。比方说你如果问我一个reddis或者postgres的kernel相关的技术问题，我有足够自信去快速读源码在一天内给一个talk把它讲清楚。而且DB/query engine及其衍生领域其实相当广阔，21年那一波databricks从我们组挖走了很多高级别的人。且不谈目前所有的reorg都是我们组吞并其他项目，我不觉得有什么情况会逼得我去接触”全新的领域“。

最后L6升职这个问题，这个是帖子的“精华”之一。没有这短短带过的两句话，我技术上讲再多也不会触动大家的神经。但一提到staff级别，那不得了，behavior门槛和仪式感得守住是吧？但promo doc我确实是一晚上写的，L5大概干了三年多一次过，4个大框大概10来个bullet points（这点其实暴露公司了）。至于能升职的底层逻辑是什么，我有不少高level的支持和own重要的领域，这个没有展开讲，但在组内有足够认可和支持的情况下确实不需要准备多少artifacts，这一点不知道你能不能理解。