漫谈技术—— 六年工作感悟

漫谈技术—— 六年工作感悟

从毕业到现在已经六年多，从个人/组织乃至国家，五年都是一个周期。五年足够让一个人掌握一门技艺，一探堂奥。人生的精力旺盛，兼具一定经验的黄金时期不过二十年，我已经度过了四分之一，有一些杂感奉上。

技术的面：

衡量一个人的技术水平是很难的一件事。因为现在行业已经走向了精细的分工，很难以一个统一的标准去衡量一个人的技术水平。

一般来说，有几个面来考察一个人技术： 深度/广度/高度；深度意味着对一门技术门类从理论到实践，以及演化的历史都非常熟悉；广度在于知识面宽广，则能够了解多个分支门类的关系，从而能够有知识的迁移。在乒乓球界，有句描述高手的话很贴切，也能说明深度和广度的重要性：

1）技术全面： 技术的广度

2）特长突出： 技术的深度

3）没有明显的弱点；

最后是建立在前两者之上的高度，因为有了深度和广度，所以才能够有洞悉一门技术的未来发展的能力。
 上面正好对应了一个完整的研究方法，譬如研究历史，需要能够横跨多个地域，纵览时间轴，从而能够对未来进行预言。

无论是整个行业，乃至一个公司或者团队，技术需求都是变化的，随着业务的变化，技术需求的变化会自然而然的驱使技术进行更新。甚至有一些当初热捧的技术逐渐被冷落，而其团队也面临着抉择： 例如走向管理或者规划，或者转投另外一个技术方向，最其次就是离开团队去需要这个技术专长的岗位，例如随着互联网的深化，有一些互联网淘汰的技术下移到传统行业；因为规划和管理岗位毕竟是少数，而且对个人的软技能要求高，因此转向一个新技术方向是大多数人的选择。如果没有技术的广度，那么这个转变过程就非常痛苦。

一个人一旦突破了自己最恐惧的点，并斩获成果。那么在以后，将借由此获得强大的自信。我经历过这种过程，要把把自己当作一个新人，亦步亦趋，扎扎实实的重新积累，好像是褪了一层皮。幸运的是计算机的基础模型的很少变化，所以我们可以找到各个领域的相通之处。例如多核并行计算技术可以看作当今火热的分布式系统的滥觞，OpenStack的设计可以看作Linux内核的继承和延续。认识到这一点，也是因为有了广度和深度才能促成。

技术与业务：

在学术界可以专注与技术的研究，针对一个问题方案进行雕琢。但是在工业界，需要结合业务去做技术，才能兼顾，不容易陷入死胡同。例如恶意网页识别问题，如果一个方案分不清楚一个网页是色情还是赌博，那么怎么办呢？ 如果纯从技术考虑，这个方案肯定有硬伤，因为无法实现准确的分类。但是在业务看来，无关紧要，因为对客户来说，无论是色情还是赌博，它都是危险网页，我们直接告诉客户这个是个危险网页就可以了，没必要吹毛求疵的要求方案。

 所以说在工业界，脱离具体业务的技术是非常难做的，特别容易钻牛角尖。我认为：这是为什么一些公司的研究院无法将研究成果兑现的原因之一。如果结合业务，技术将会事倍功半，甚至能够及时规避一些难点或者不可能完成的点。

同样的例子发生在游戏设计上，当初小岛秀夫试图设计一个火爆的战争游戏，但是由于当时的技术和硬件限制，而设计了一个节奏偏慢的潜入游戏，结果大获成功。相关案例不胜枚举。

技术/规划/管理：

我在《漫谈行业》说过： 技术/规划/管理就好象是一种三权分立的职能结构。其中规划可以类比立法的机构，规定产品需求；技术负责实现，恰似行政职能；最后是管理负责管理技术进度，以及是否正确的执行规划的意图，类似与司法。

就像是现实世界的三权分立没有真正的实现一样，技术/规划/管理从来都不是泾渭分明的角色。有时候，技术会干涉产品，越主代庖。也有的时候管理会强势的拒绝产品规划的需求等等不一而足。在真正执行的过程中，会出现一方占主导的地位，从而达到统一意志。就像当年美国行政首脑罗斯福可以干涉立法一样。
  据说一些国外厂商的研发地位是高于国内的同行的，一些业务需求提交到研发，研发可以认为技术不可实现，或者影响整体架构的演化而拒绝。当然这也有一定地域歧视的因素。对比来看，国内的技术地位要低很多，一般是产品规划或者管理主导产品开发，研发人员很难决定架构设计。国内往往需求来了，照单全收，疲于应付。架构迅速腐化，过度消耗了一个架构的生命周期。有人说：国外强于技术创新，国内善于商业和业务创新。到底是研发的弱势还是中国人特有的业务变通能力造成这个现象，一时难分。

三者的关系是互相影响的。例如技术架构就可以影响人员构成，例如微服务架构就决定了小团队的分工协作方式；组织架构同样能够决定技术实现，例如部门墙的问题直接导致开发测试运维一体化是句空话。同样产品规划也能够决定组织形式和技术，例如互联网的快速迭代自然决定了技术需要实现大量的解构和业务拆解，否则难以快速变化，同时在组织上也必然放权，因为上层需要释放基层的主观能动性。就好比过去的农业经济自然而然形成了一种集权社会以求的成本的最小化，规模最大化；而商业为主导的经济就需要灵活应变的组织结构，应对供求的变化。

各个职能其实有一些交叉的岗位，例如技术管理岗位兼具有管理职能和技术职能等等。在几个岗位中，要数架构师这个岗位最尴尬。架构师如果没有管理的权利，那么其充其量只是一个参谋人员，充当管理人员和规划人员的幕僚，只有建议权而无决策权。所以不只一本书提到，架构师本身一定要赋予组织管理的权力，否则无法实现其职能。这也是真正的三权分立在实践上无法真正实现的原因。

技术的成长：

技术就像一门手艺一样，熟能生巧。在新部门我发现有一些工作接近10年的同事，确实无论是编程的准确和对知识理解的透彻程度都远远超过新人以及6年工作的人。有些技能的点确实需要长期积累。

幸运的是，接触一门新技术都有一个学习曲线。如果靠有技巧的学习我相信是能够在短时间达到一个领域专家的六成的水平，而随着后期不断的时间投入，边际成本越来越高，所以后面的四成技术水平往往要消耗非常多的时间成本，才能够得到。所以最经济的办法是集中精力在短时间内迅速突破，达到六成的掌握水平；其后，随着需求专门性的学习，最后日积月累，集腋成裘。

技术学习的有两个阶段最困难：1） 刚接触到新技术时； 2） 已经掌握了一定程度，但是发现遇到了瓶颈，突破不了；

前者是属于一种接触到新技术的陌生感和恐惧感导致的，就像是我们看一个电影，为其绚丽的特效震惊，而忘记去解构它，实际上是新瓶旧酒而已。所以一个新技术往往是其噱头和包装导致我们的恐惧感，如果我们通过知识的迁移或者解构，就会克服恐惧感。

后者是一种我们成长为技能墙的东西。大部分人遇到技能墙时候选择放弃或者停滞，很少人去再主动突破了。就我的工作感触来说，在一个细分领域能够持续耕耘的人非常少，甚至当你耕耘多年发现国内甚至国外也无几人，甚至大家都认识，形成一个小圈圈。

我认为技能墙的突破有几个要点：1） 持续不断的投入； 2）洞悉核心的原理，明白技术核心的矛盾；3）正确的方法，例如有一些技能确实看书和实践是两码事，如果不动手实践是无法达到另外一个层次的。又例如，初级的程序员以来于调试器，而高手则靠读代码分析代码，少的依赖调试器。因为调试器会把人变成一个只会看输入输出的自动机。

 技术的溢价与周期：

任何技术都有周期的，有盛有衰。在从萌芽到最后的热潮，最后衰退。最佳的时期是即将迈入风口的时期，这个时期一将难求，有价无市，重金都难找到一个专业技术人才，这也是技术的溢价期。
   随着时间的推进，很快各个培训以及个体趋之若鹜，如过江之鲫，最后技术走向一个合理的价位并且逐渐推移走向衰退。即使不走向衰退，这门技术也会由于市场的需求，而逐渐变成一项基本技能而不是加分项，如机器学习未来可能如操作系统一样深入人心，成为基本必修的技能。

学术界在这一点跟工业界也是一样，也有风口。一门新方法提出之后，初时无人问津，后来突然被发现有效之后，遍地开花，期刊也乐于接受，直至不胜其烦。可谓其兴也勃也，其亡也勃也。所以就像是工业界一样，学术界很少人去一辈子专精于于一个领域，往往有一定的广度，去承载学术领域的周期变化，否则将难以保证学术成果的最大化投入产出比。

每一门技术的周期规律都是如此，只是延续的时间不同。周而复始，至死方休。