到底什么是technical？

凡事皆有缘，遇到一个人，读到一本书。是的，一本书，最近就读到一本有缘的书。缘起StarWest 2010，听了James Bach的tutorial，然后得知他老爸是著名的畅销书作家Richard Bach，写了一本著名的书，叫做Jonathan Livingston Seagull，台湾翻成《天地一沙鸥》，内地则译为《海鸥乔纳森》。网上查了一下，原来如此有名，而且更巧的是，最近看到一部讲单车旅行的台湾电影，叫《练习曲》，里面有一段就是一个人在朗诵这本书开头的一段。

这本书很薄，简中版还配有漂亮的插画，很适合旅行，很适合我这种看书慢的人。

这本书在讲一个叫做Jonathan的海鸥不甘心每天为了小鱼和面包屑的生活，认为对于一个海鸥，飞翔有超越为生存而觅食的意义，于是疯狂的练习飞行的技术，甚至不害怕叛逆。书中有很多关于飞行的细节的描写，可能因为Richard老先生本身是一个飞行的爱好者，所以那些高难度的动作看起来那么的有趣和真实。

当在飞机上读到Jonathan在痴迷的练习各种高难度的飞行技巧，并且不断追求更高的境界，不厌其烦，不害怕失败，我忽然领悟到一个词的意义，technical。

我领悟到的technical有点不同于我们现在常说的职业发展中两条路（technical track ang management track）中的一条。很多时候我们理解的technical就是研究技术，去做具体的开发和执行，management就是去管人或者管项目。这种划分更多是从工作的内容来看的。

我现在对technical的理解是一种观念或者精神，是一种追求卓越和精益求精的研究精神。这种精神就是不断的探索和要求自己怎么可以把一件事情做得更好的专业精神。这种精神并不只是和IT技术有关，而普遍存在于各种地方。不信？那我举些我看到的例子。

F1，这是一个我最先想到的例子，这个速度与激情的竞赛，胜负只在毫厘之间。这毫厘的差别如何得来，调教发动机和变速箱；调整空气动力套件来使用不同的路面和风速；换不同的轮胎；轻油和重油的策略，对于车手而言，在大直道把车速踩到350以上，如何要考虑在快要进湾的时候在什么地方开始减档，松油门，或者踩刹车。在听解说的时候会很奇怪为什么解说员知道在什么地方车子是几档，而且会发现大家在同一个弯道走的几乎是同样的线路，因为这是不断摸索出来最优的路线。这里到处都是很technical，不去钻研这些细节的车队和车手是没有前途的。

运动员。优秀的运动员，都是很technical。因为高低的差别也在细小之间。体操和跳水的一个动作、射击的精准、网球的动作。那些卓越的选手总是在不断的挑战自己，不断的寻找更好的办法来提高。很多时候，付出20%的努力就有可能做到80%的程度，但是剩下的20%就往往是很难，努力很多才会进步一点点，但是这就是通往卓越的旅程，需要不断的去钻研，去尝试，去失败，去反思，去挑战，去学习，然后再去挑战。

摄影。自单反流行，似乎到处都是摄影爱好者。但是绝大多数人都是快门杀手，很多的功能都没有用过，不知道什么是光圈，什么是快门，什么是曝光补偿。当然，对很多人来说，这样也就足够了，一个更好的工具。但是我也在身边遇到另一种人。他去研究如何用公式计算景深，镜头的不同焦段和光圈，以及距离带来的景深的差别，然后不同厂家的镜头的区别，并且反复练习拍摄去印证，看看不同的光圈会带来什么不一样的效果。甚至还有一些人有黑客精神，去刷相机的软件，然后调出工程模式做一些更细微的调整，比如对焦的精度等。这是两种不同的态度，也无所谓对错，就像我这里说的technical一样，只是一种不同的观念。

然后我们还是回到软件行业，其实也是如此。写出基本能用的程序也许不需要很努力，但是可能响应时间是10s，如果想要提高到9s，也许要付出另外20%，再到8s就要付出更多的努力，然后问自己，有没有可能做到7s。也许有些时候，10s和7s没有分别，但是很多时候，它也可能是区分平庸和优秀的产品的一个指标。很多个这样的指标叠加在一起，两个产品就完全不在一个层面。

这样说来，technical一词的意义有点像是奥运所说的更高更快更强。就是那种绞尽脑汁去想如何用更少的东西，在更短的时间，把事情做得更好，把东西做得更强。

很多时候，technical不是知识和技能，而是观念或者想法。最近有一个自己身边的例子，team有一个用了好几年的性能测试工具，用来快速的接收邮件。很多人在用，但是大多数人也只是在用，大家都知道它很快，但是到底有多快，没几个人去追问。有次sharing的时候我问了介绍工具的人，这个工具收邮件的能力极限是怎样的？他说测到了100多封每秒，然后team另一个人说差不多。我问他数据是怎么得到的，他说这么用过。我想说的是如果一个人想知道这个工具的上限，他很容易找到办法测出来。但是这个问题的差别在于有些人想知道，有些人不想知道。而这不是知识和能力的问题，而且观念的问题。记得在刚开始用到这个工具的时候，我和另一个同事很好奇它的能力上限，然后设计了一个环境来测试。考虑到需要1Gbps的网络，但是当时找不到这样的交换机，就从家里带去自己的Thinkpad T43，作为工具运行平台, 和作为client的PC对接，但是发现T43的能力不够，因为CPU已经满负荷，这个时候已经能发到每秒1000多封了，但是看来还没到上限。一起测试的同事于是带来了他新买的T60，1G的网络用满，T60 CPU 70%左右，已经能发到三千封了，看到网络已经是瓶颈了，然后我们截了几张图来记录测试的结果。这样我们就知道了在我们现在的测试环境里面，这个工具可以提供给我们的能力，在后面的工作中，因为知道这样的上限，很多时候在测试环境的设计的时候心里更有底了。

这是一个小事例，在这个例子中，我和那个同事很technical。

如果是这样来理解technical，management并不是它的另一个平行的方面，而只是另一个领域而已。或者说在任何的领域都可以technical，只要是去追求卓越，不放过细节，努力的探求更好的方法、技能和工具。当然这种方法也不一定就是去硬磕，也可能是很柔性的四两拨千斤的方法。而最重要的是有没有一颗和Jonathan Livingston这只海鸥一样去追求卓越飞翔技巧以及不断突破自我的心。各行各业都是一样，前一阵去台湾旅行，很不错的旅行，其中一点是因为我们有一个很棒的导游。他和我之前见过的所有导游都不一样，他自己就是一个喜欢旅行的人，他对我们去的景点有非常丰富和细致的了解，包括这个地方的历史，地理和气候的因素，附近的不错的小吃的地方，还有关于很多植物的介绍，然后在大巴车的屏幕上放出他收集的很多资料和照片来讲解，中间也有很多和大家的互动。而不是像之前遇到的很多导游一样在背导游词。按我的理解，他也是一个很technical的人，对于他的这个职业非常的technical。

说实话，我有些厌烦很简单的人把软件行业的工作者分为technical和management，而且也不认为这是很合理的。我能想到的就只有一个原则，那就是把你的事情做得更好更专业，这样的目的可能要求你去研究某个技术的细节，也可能要求你去思考如何带领一个团队把事情做好，如果你现在的scope有这样的要求。所以不要太被这样的term困惑或者束缚，而更去思考如何才能做得更好，就像海鸥Jonathan，他一开始是在一个人拼命的研究和练习飞行；然后跟老师一起学；然后他也成为导师，带领团队也培养别人。一起都是很自然的事情，我想他大概不会去思考什么track。