Always Hands On

节前在北京和ZWJ同学聊了一下，然后就写下了上面这个标题。其实前两年开始这个想法就在内心里发芽了，到了去年开始关了之前创业的业务，然后一年了重新 hands-on 写了很多代码，投入新一轮的 AI 大潮之后，算是更加做实了这个想法。

很长一段时间里，无论是自己创业，还是在公司里带团队，都会纠结于到底自己要多 hands-on 写代码吗？往往纠结下来的结论是不要 hands-on。往往得出这个结论的原因，还是 ROI。无论是在创业还是带团队的时候，都容易得出一个结论，公司几十号人，让大家各司其职更重要一点。很多年前，我还专门翻译过黄易山写的技术管理者应不应该写代码，表示对别太 hands-on 的认同。

有趣之处在于，尽管十多年前我从理性判断得到的结论是不要太 hands-on 写代码。但是实际上过去十来年里，我倒是真的没有把写代码这个事情给扔下来。一方面，是过去好几年都在创业，所以总是会遇到一些自己动手把事情干了更快的场景。而且和在公司里带团队不一样，创业的时候遇到这种场景，往往也没有什么更好的办法。毕竟不像大厂什么技术领域都有专家，如果没有的话也可以想办法招一个来。创业公司一是没有，二是想找一个即使给得起钱别人也不一定愿意来。当然，另外一个原因就是，写代码还是比操心业务有趣多了。干得好的技术人，往往不是喜欢”卷“，而是真的享受写代码的快乐时光。特别是有一些有趣的需要思考探索的新问题的时候。

所以随着我自己看得越多越多，过去2年，我在到底是 hands-on 还是 hands-off 这件事情上的观点，有了很大的变化。在面试了更多的人，看了更多的团队，在一个更长的周期看不同公司的业务和境遇起起伏伏之后，我发现原先的结论是错的。错误的核心原因就在于，hands-on 是唯一能让你保持对于技术的 Vision 的方法。甚至可以说只有充分、大量时间的 hands-on，才能让我自己对于技术的长期决策有一个正确的判断。其实过去一年爆火的 AI 就可以看出一些端倪来。尽管常年压了重注在AI上，但是 Google 在这一轮 AI 的浪潮中属于一直被 OpenAI 吊打的状态。其中一个核心原因，就是 Google 对于 AI 到底能进展到什么程度的 Vision 层面的判断完全错了。而回到 OpenAI 这边，据说总裁 Greg Brockman 自己撰写了大部分的 OpenAI 的模型训练的基础设施的代码。我相信，正是充分的 hands-on，让 Greg 以及整个 OpenAI 的核心团队能够对到底 Transformer 架构下靠大力出奇迹能够走到什么地步有充分准确的判断。

回到过去几年，也帮朋友公司面试过各种大厂出来的 leader。如果要给一个结论的话，就是在完全只管带团队，hands-off 一两年之后，大量的所谓大厂 leader 对于一个需要探索创新的技术或者业务基本提供不了价值。如果没有来得及转变成优秀的背业务目标的业务 leader 的话，其实人就废了。而且这个废了，在还在大厂的时候其实体会不到危机感。因为在大厂内部完全可以依赖自己作为一个老员工的信息优势和工作惯性显得还不错。但是实际上，对于业务的帮助和找我奶奶去管那个业务并没有什么区别。

这次和ZWJ同学聊，更是从另外一个角度交叉验证了这一点。他的性格已经是非常 hands-on 的了，但是在面临可能会出现AGI这样重大的技术变革之时，每天都在一线动手才是唯一可行的道路。当红的巨头公司，用几倍的人力物力，一时半会儿也没有对一线的优秀创业团队打出优势局面，也说明了这一点。从各处得来的切身体会，以及我自己的体感来说，一个优秀的一线动手写code的工程师，在这个阶段的战斗力，一定是能抵得上大公司一个小团队的。如果说，以前大家鼓吹的“10 Times Engineer”，在一个传统和成熟业务上也许有些神话了。但是在探索未知的创新业务里，“100 Times Engineer”，也是普遍存在的。

归根到底，是AI和软件开发这个行业本身还是处于早期阶段，它仍然是一个手工业，而不是大规模流水线。或者说，流水线的部分并不是竞争真正发生的地方。如果你的目标是创新和Tech Vision，那么“Always Hands On”也许是唯一的选择。