十年职场两茫茫，回首反思一步错
2020-7-9
牛经沧海
2000夏天我的投资亏废了（主要是ARBA与JDSU等等明星天使坠地），重回职场。钱钱输光了，人就特别专注。每天干活前坚持阅读80页。很快读完Sybase全部2500技术文本，另加几本相关书籍，从一个外行变成一个“专家”。当时我们部门的产品搭建在client-server架构上，随著交易量暴涨至设计能力的4倍以上，Sybase成了瓶颈。公司CTO几乎每天都要过来督战，以免在CEO哪里讨不自在。这就是当时死磕Sybase的起因，就好像发现一个费马猜想的解法。
那套系统几乎是当时在位的架构师（SVP衔）一手打造的。有了问题，他不让别人动手。可惜他对Sybase新的发展不甚了解。我们每次开会讨论问题，他听不见别人的建议，尤其是我这个外行。一次又一次，我指出他的不正确之处，后来，他会后查证我是对的（不对我哪敢说呀，是吧）。他技术好，早年卡内基梅隆CS的PH.D., 人也很正直。凡是他查证我对了，都会在下次会议上肯定。
几次下来，部门负责人（也是SVP）单独给我一个模块调试，我一星期搞清逻辑，是一个n-to-m的matching问题，正是我的强项。经过我的修改，减少Sybase spindle锁定时间98%（可以说成提高性能50倍）。其实算法改变带来的性能提升是非线性的，不能用百分比衡量。
后来又拿来几个模块，都又不错的效果。有一天，老架构师来到我的工位，送给我两本书，说他退休了。滞后一年，我将整个系统全部过了一遍，处理能力提升8倍。
正在我春风得意的时候，犯了一个大忌。当时CTO另一个团队正在开发一套n-tier架构的替代系统。老的系统性能大幅提高，无意中对新系统原来的性能目标是一个挑战。果然，新的系统集成测试，四处冒烟，远远达不到老系统的处理能力。
新系统的设计师这时来找我，也在意料之中。他的团队没有一位精通算法，对Oracle也是一知半解。起初他们依赖DBA帮助调试，但DBA只是在Oracle参数设置与Query上下功夫，难以对系统全局的逻辑产生影响。眼看我扬名立万的系统即将被替代，我也不能闲着。其间，我用5个月考完Oracle DBA，摸透了Oracle的内在特点，预感到那些常年使用Sybase的人会犯很多错误。果不其然，所谓n-tier，还时没有彻底摆脱数据库一环。
做完这套n-tier的新系统，得到新老两套系统团队的认可，一时风光无二。遗憾的是， 赶上连年熊市， 交易量萎缩，公司被桥水收了，我们各自散去。
我们团队中不少人后来做到MD， 其中一位印度经理，因为领导n-tier产品有功，升职至SVP，去新公司带去5位初中阶经理。邀我，我却独自去某投行当时正火爆的衍生产品部门。几年之后，他已经的团队扩大到2000多人，随去的各位大多做到MD。后来我所在的公司倒下，我去他那儿谋职，他已经不再关心任何技术能力，将我引荐给他技术部门的头头，也拿到一个奥发，还是技术类。
拿上这个奥发去跟现任上司恳谈。上司也是一位老印，立刻把我吹捧云里雾里，足以让我放下转职的想法。当时感觉离MD很近了，弃之可惜。没想到这哥们摆了俺一道。后来大衰退日益严重，我被砍了。
回看其间十年，教训是
（1）技术只是敲门砖，有它不错，没有也行。敲开门以后不可恋栈，头头们只有7秒的记忆，该立即转向发展管理职能，否则难有大成。我本来有机会转向管理职能，可惜贪恋搞技术不求人，而做管理要处处求人。错错错。
（2）不要听信上司的迷魂汤，要砍人时，他不会记得跟您JB过什么，他也许每天对每一位手下都那么表演。
（3）单打独斗走不长，一定要趁早发展自己的队伍，越早越好，越多越好，越大越好。
俱往矣，事后人人诸葛亮，当时个个不思蜀。
