跟朋友吃着饭，说接下来看个什么电影去呢。看着四月份的烂片列表无语，居然五十度灰还在放。他笑了起来，说他妈七十岁生日那天自己去看了五十度灰。看完，用一句台词总结，what the，哈哈。思路（浑身肌肤都）需要捋的时候，为什么被别人捋不是虐心是享受呢，因为能激发一点想象力吧。
他问，“五十度灰什么意思？”
“无非一层层把过去的遭遇剥出来。” 我想了一想。
对软件工程的发展有二十几年的感觉，也积攒了一些程序员的经验，开篇的调戏是为了防止后面没激情。（You know, I noticed my male colleagues write "0xBABE" "0xDEAD" when they initialize byte arrays. Subconsciousness... what a lonely profession.）
我父亲是水文领域的计算机专家，因此我小的时候接触计算机非常早，几岁的时候就用过打孔的纸带，八进制的。但是接受了他的理论，计算机只是工具，为各个专业所用，反倒没报计算机系。因为我喜欢物理讨厌化学所以最后选了材料科学，比计算机或电子工程更好申请奖学金，因为出国是早就定好的目标，可以开阔视野。最后在美国读金属材料不好找工作，赶上 2000 年的泡沫又转回到计算机。
入行具体做网络通信，而且先是个偏门，control network，2000 年在做智能家居的东西，在 JavaOne 上发布一个 demo，移动端是 Palm Pilot。后来做智能大厦 building automation, PC 端的东西。再后来回到 data network，Ethernet AV streaming 的固件。最后八个月转领域做了 flash controller firmware。这几次转换相当于三个处女期（通常是一个月），几乎都是愉悦压不倒痛。以IT业的节奏，程序员一辈子只当一次处女恐怕难求。
现在还清楚记得第一个月上班天天沮丧，跟的高级工程师在 port 一个几十万行的 C++ 产品去 WindRiver 的新版。不写新 code，porting existing code 貌似简单。CS grad，编译总会吧。没想到编译出的错，dah，以zillions 计，一个月都没解决干净。还记得有些人注释写//不是/* */。＂Son of bitch!＂他气得冲出办公室找那些人算帐去了。这就是为什么以前要写 portable C 的规范，现在的 compiler 哪个不能处理这个，lol。除了这些低级问题，还有 WR 的问题，我又不熟悉本公司的代码，又不敢乱改，又不是时时逮到人能问，只能没日没夜加班砸时间熬。最后老板看出来老工程师一没好好带，二也不适合新手做，把我抽出来做 Java 小项目。相关的codebase 小，入手就快（Size matters，带新人的程序员切记）。Port 一部分 C++ 去 Java，还有的用 JNl 调用。这个非常好，让我熟悉了两种语言的 mapping。而且 Java API 是多么的好查找好调试，呵呵，以至于迄今我对 C++ 过敏，能写 Java 和 C 就不写 C++。（电影里怕她第一次对鞭子过敏的有木有。）当然 C++ 是Windows 时代 desktop shrink wrap software 的首选，和 visual studio 还是很好用的。我老板做得非常好的几点是，看到我加班就说，“回家，加班太多了做不长久”。而我 Java 这边一做出点东西大加赞扬。每周固定时间1-on-1，聊完了工作聊别的。我后来因为个人原因跳槽，他二话不说要 match 下一家的工资。所以离职很久了我仍然给他寄圣诞卡。
在这家公司做 OSGi 的实现，G 是 Gateway，for networking，跟 Eclipse 本来八竿子打不着。不得不服美国技术思路流通块，好的思路拿来用，原来的项目死了，用得成功的反而更有名。Eclipse 第一次设计大转型后，基于 microkernel 加插件的 OSGi 构架。Eclipse 已经很复杂化了，毕竟是 IBM 的班底再开源的。IBM 的哪个产品都有点航空母舰状。我们做的比较 micro，硬件盒子基于 Linux 的，Insignia 的 JVM。我经历了 J2ME 的诞生，想当然 JVM 可以在任何硬件上跑。（今年和移动端开发触电，what the，Android 和 iOS 是两套？同样的活，干两遍。Give me a break.）
后来换了个公司，又赶上内部 reorg，有两个组选择，去做 PC tools，虽然是配角，老板很 nice，同事全是美女，至少还是 PC software，熟悉。另一组是 firmware，全是男同事，老板也比较硬，问题是，我没做过firmware。但这是核心部门，正缺人，裁人的风险小。去吧，要养家糊口呢。一上来，当测试，firmware 部门原没有专人测试。（犯了 Joel Spolsky 的软件开发十诫之一）呵呵，测试其实是对新人的一个好安排。除了一条，没有测试文档，这就把原本简单温柔的工作性质变了。我既要看 IEEE specs，印出来几大本一尺高，又要看code 实现。还好跟 control networks 是相邻领域的，只是 packet format，flow 变了。当时 firmware 组在五楼，没位置了，我新来坐四楼，反而和 DSP 组的人一起吃饭聊天多些。每天 Email 楼上的问问题。有一天我忘了是问什么小事了，结果引动牛人下楼来大骂，能不能少问这种问题，这都不会还做什么做啊。隔壁 DSP 的人都动容，这是怎么了。（天天吃饭的同事是不会这样对你的，小笨我没尽早去打理啊。）情绪上的反胃靠加班压制，别人不就是嫌我慢吗。有一天很晚了，人家下楼来看到我，脸色就和缓多了。我说 audio test sample 那首歌真好听，尤其在公司清净无人的时候。“哦，Forever at Your Feet。那是我特别的歌。”（歌后面是有故事的喔。）结果两年后他离职的时候，组里就我哭得眼圈红红。他说，他在那工作三年，能得了两个人的眼泪，也值了。他走以后，我们的产品和 Apple, Broadcom, Harman, LabX 做兼容测试的时候，老美喜欢放摇滚，我们总放这一首有点凄凉的歌。凄凉到最后，一连走了7个人。我试图向上进言，未果。现在发现，当牛人的付出不得承认并且被错误对待时，一走会走一片的，众人都会心有戚戚焉。
我最后一个走的。Flash controller 公司热的时候不好招人，做过 disk controller 的上，单跟 firmware 沾边的也上，像我这样的。（跟现在移动端招人像不像？火线上岗。）第一天老板讲话极快，后来知道了他是 brilliant engineer， (慢一点会减少痛，好吗)， 二十分钟入职培训讲完了。派我边看 code 边 fix bug，这是培训新人的正常方式，正舒口气。两天后，不好了，是个 timing related bug，有时出有时不出。这个也会做，多 run，想办法让它一直出。但和 networking test 传包解析包结果立得不同的是，flash 很多 test case 是反复读写，有随机性。我要用的特殊 case 要 run 2-4 小时。百般造简单 case 的尝试不成功，这就去了一个多星期了。老板说，还是用原 case，事后证明他的方向是对的。两个星期的时候，我看到 code 里有一个 switch case 没有 break, falls through，是一个state machine，注释不太多。试吧，加上 break, pass, 拿掉，fail。特别小心地把全体功能性 test run 一遍，至少没有 break 别的东西，夜里兴奋地 check in the fix。第二天被老板 revert。 解释是需要 fall through，这只证明是 timing bug。跟 chip designer 谈谈？那人已经离职了，跟接替的人也没套出什么来。继续折腾不同时间点的 build，娘啊，一天只能 test 几版，SVN commit 每天都是几十个，好不容易得出另一个 hint, 两个月前 fork 的某个 branch passes, the trunk fails. 这就是时不时 branch 要承受的痛. 在source control 里 branch 一下很容易，就按这个客户的需求改一点交出去，快啊，不影响别的功能开发。（容易的快感要抑制，才会爽得久一点。）那就死磕两边的 diff 吧，特别多，肯定先注意 functional changes，不会去看那些 printf。每天 6 点一睁眼就 VPN 看 lab 里前一天的 test 有没有结果，然后再 run 上一个，9 点人到公司能看结果，晚上 8、9 点离开公司时 run 一个，睡觉前还能再 run 一个。（不是程序员的人看 Imitation game 会对这种跟机器打交道的孤独、挫折和坚韧有切身之感吗？）最后让人泪奔的结果出来了。Pass 的 branch 里有几句 logging (类似printf)，在 trunk 里被注释掉了，影响了 timing。将近一个月过去了，两周一版的 release 赶上了第二个。我颇有点抬不起头来，一个 bug 花了这么久。多数 team members 和老板都比我年轻，平常也不叫我一起吃饭，真不是一个好的开头。
几个月后，我决定辞职学中医去，不想做新项目了，老板让我把 codebase 重整一下，因为每个新项目都是 clone the old codebase then modify。如果每个新人进来都像我那么挣扎，公司损失大了。（真是哪壶不开提哪壶。）Refactor 绝对是个吃力不讨好的事，同事不欢迎，极大影响进度，出错的风险大，程序员也不愿意报绩效时没有具体实现新功能。我很愉快地同意了，和各方沟通，把 C 文件拆分，模块化，解决混乱的 dependency问题。C 写好了不比 C++ 封装得差，效率不用讲了。过程中用了几个 eval 版 static analysis tools, 包括 coverity （后来认识王垠的时候才知道是他做过的产品）. 最后因为 dev seat 实在是贵，不能让 50 个人全装，选择让一个负责程序员来管理，不太理想，但绝对强似于无。这些 code analysis tool 应该在每个程序员加新 code 前时不时 run 的。
最后跟老板 exit interview，他才讲，我后来一次做的一个功能让他知道我的水平。（经理们，员工的士气要随时鼓舞，不要等到他辞职。不给足小兴奋会让人变性冷淡，一样的道理。）一个韩国工程师做了几个月的一块，怎么都有 bug 通不过。我三四天就做好了。当时我一看那一堆 code 散在好几个文件里，思路也奇怪，就干脆删了，照着 SATA spec 重写。Spec 就是告诉 implementer 和 tester 有哪些 case，怎么处理等等。哪像我第一次遭遇的 bug 是一大片混沌，无章可循，而且我除了被告知公司的 flash 装在 iPhone5 里面，flash 怎么 work的自己去搞定吧。但是另一位年纪大的韩国同事很有心，收集文档在 wiki 上，平常看他说话做事不是那么灵光，在组里地位也一般，但在帮助新人上功劳是很大的。这就是 team building 的艺术，经理要掌握好。
好了，总结下虐心一二三。不要让处女程序员情感上落单，也不要一上来就用鞭子和手铐，大项目的不要，稳定性 bug 的不要，要 sit together, eat together, take it slowly, do it the regular way。拿王垠在Google做 Intern 的经历来举例，他不是正常人，也不是 virgin，还落下了后遗症不是吗。：P
