优秀程序员还得有个标签：可控性
读到CSDN的一篇文章《优秀程序员的首要特性：判断力》，作者讲了一个故事来说明作为程序员判断力是如何重要。节省时间，我把故事贴出来：
引用关于Jack和Dianne的故事
Jack是一个摇滚巨星。Jack喜欢谈论世界上最酷会议中提到的最新发展趋势。他很重视在一个新项目中使用三种以上的新技术。当请他做一个基于互联网的控制后台，用于将烹饪方法与厨具进行匹配。他投入很大的精力开始做此事。最终该后台中用到了Google Protocol Buffers、node.js，具有可扩展性，却很难维护。
Dianne是一个优秀的程序员。最初Dianne是一个Unix 管理员，两年前才开始做Ruby开发。当被要求开发一个同样的系统时，她首先问了以下几个问题：
“预期会有多少厨具？”
“我们希望12个月内卖出500套厨具。”
“需要多长时间出一份报告？”
“大概一小时一次。”
“这网络的可靠性如何？”
“使用WiFi，它很稳定。”
Dianne使用MySQL数据库写了一个RESTful API结点。PostgreSQL可能更适合，但她只懂MySQL。
Dianne采用的这个解决方案可以扩展到1万个用户吗？不能，但这个系统并不需要这样做。Dianne的解决方案很简单、容易理解，具有更好的维护性。Dianne知道它并不是最简洁的解决方案，但她却知道任何更复杂的事都会超出她现在的能力。
看到这个故事时我的第一反应就是：神呐，让Jack用三年时间维护这个系统吧。
因为我之前遇到过像Jack这样的同事，碰到人就海吹新技术，且在产品线上的AS程序中频繁使用这些新技术。如果能保证质量也相当好，主要是不能，每次都是别人替他擦PG，久而久之，他就成了产品线上的“DEMO大师”。
大家以前都听过，产品的生命周期中，维护占着95%的时间，如果在2~3%的开发时间爽了，那么之后很容易陷入无穷无尽的苦难（和生小孩一个道理）。所以Dianne的优秀之处就在于：PostgreSQL可能更适合，但她只懂MySQL。她之前在MySQL上的经验和教训就能传承到新的项目中，对自己所用的技术自信且有能力保证产品质量。我觉着程序员对产品的可控在于：自己能力适当，对常用的基础产品可以掌控（DB，Cache，网络等逻辑架构熟悉，常见bug都能fix），对产品架构扩展有足够能力。不管是同事，客户还是领导都会信任这样的队友，我觉着这就是优秀。
其次，我很认同Dianne做事风格的一点就是，提前将产品的环境与容量搞清楚。就从我自己还有接触的同事来看，很少有人去管与产品容量规划有关的事，总觉着是Leader应该处理的范畴。如果产品的用户就是一百万，我们就做一百万的设计与规划，有适当余量是可以的，但不要考虑太多当用户是两百万时怎么办的问题。这个话题另说吧。
我这样说肯定有人质疑说，程序员应该是对技术敏感的，如果都用自己会的技术，对产品和个人发展不利。但程序员对新技术的敏感是与产品的稳妥性相冲突。程序员对技术的前瞻和创新首先应该是在自己的头脑里，不能抹杀这种热情。接着将自己的大胆想法做出原型与试验，证明它可以用在产品线上。在不断地仔细验证之后，才能将程序员的想法用在产品环境上。所以我的总结是：头脑跑在前面，试验新的技术，用最稳妥的技术。Jack使用新的技术没错，但不可控，如果出现问题的话，产品环境被拖累，自己也会很疲惫。
一己之见，诚请批评 1 楼 langyu 2011-11-08 请在点踩之前把你的意见留下，不然这算什么 2 楼 wanghuazhongzju 2011-11-08 呵呵。。denny,好久没更新博客了吧。。
其实我觉得主要是看问题的角度不一样吧。程序员都喜欢从技术的角度，要用最牛逼的技术来做一件事情。而产品经理关心的就是产品的实用性，他才不管你用什么技术做，只要产品能做出来，符合现阶段需求就行了。。
所以程序员应该不要不局限于技术层面的东西，再牛逼的技术都要以实用为主。。。 3 楼 langyu 2011-11-08 wanghuazhongzju 写道
其实我觉得主要是看问题的角度不一样吧。程序员都喜欢从技术的角度，要用最牛逼的技术来做一件事情。而产品经理关心的就是产品的实用性，他才不管你用什么技术做，只要产品能做出来，符合现阶段需求就行了。。
呵呵，是有一段时间没更新了。牛逼的技术也会带来很“牛逼”的bug，这可不是你能不能解决bug所能控制的。当别人知道你对你用的技术了解的不透，那谁信任你？其实就是说，我们在用自己的牛逼技术透支上司的信任与客户的忍耐。
我相信没人一直想做coding吧，不管是站在架构师或项目经理的角度，项目是否高可靠性是不可避免的事。这里的高可靠一是指项目本身质量，二是程序员本身，你离职了谁来代替你维护呢，你觉着呢？ 4 楼 houxinyou 2011-11-09 工作和学习不同，工作要做到稳定，学习要创新。牛逼的技术是学习时用的，当你学的很熟悉的时候才能用到工作中。
就像选择电脑，服务器，最重要的是稳定！哪怕慢一些也好。每小时能稳定的处理10个任务要比的每小时处理1~20个不定任务要好。 5 楼 ada_li_li 2011-11-14 曾经也以"demo大师"自居过,因为学东西比别人快,出活儿似乎也比别人快. 不过后来特别头痛维护自己写过的程序,就想扔给别人.
换位思考一下, 如果必须"eat your own dog food" , 程序员写出的东西可能就会是另外一个思路. 6 楼 langyu 2011-11-14 很感谢楼上几位可以这样看
我是实在想看到反对这个观点的同学持有怎样的想法呢 7 楼 jiafu1115 2011-11-17
我觉得分阶段吧：
可能才开始学技术都想当DEMO大师，尝百草，等都有点知道后，才可能淡定地做点事情，哈哈 8 楼 wangjinpeng 2011-11-18 你常用的不见得是可靠的, 你没用过的新东西也不见得是不可靠的, 做事情么, 我觉得实事求是做好每一步就好了, 思考-->选型-->讨论-->Demo-->测试-->重构, 稳定是相对的,如果每个步骤都做的很到位,那就可控了,如果做了设计不讨论,写了代码不测试,系统上线不监控, 那在熟悉也是不稳定的...总之我觉得程序员做事情尽量从实际情况去考虑,用不着害怕什么新的旧的,新的合适就用新的, 当然用新的也是有原则的, RC版本, 有社区支持, 有深入问题debug的能力, 这些是基本原则. 当发现系统难于维护,难于扩展, 该重构就重构, 没有魄力咋行...
我就挺欣赏Jack, 有激情, 关注新技术, 能找到将新技术融合进项目的点, 并且考虑扩展性, 而且喜欢酷的东西, 虽然有时候不太合时宜, 他缺的仅仅是经验和一些合适的搭档.
"Demo大师"我想要么是他缺乏耐心浮躁技术能力不够,要么是没有得到team的全力支持,要么就是一开始需求设计就偏离了...team里面有个Demo大师其实还是挺幸福的事情... 9 楼 langyu 2011-11-18 wangjinpeng 写道...
谢谢Jinpeng的提点，组内能有做DEMO很快很好的同事，当然是福音，既能提高大家对新技术的敏感度，又能激发团队合作的动力。当然谁都不希望在产品线上做DEMO，说实话我是被这样的经历搞怕了。技术不管新旧，好用就成，但一定得验证，且使用的人得有经验。这种经验来自于之前的开发或运营经历，有继承性。同意你的说法，程序员在想法上不要畏手畏尾，大胆提出，但一定得小心论证。这与对产品线的可控一点不矛盾。Jack缺少经验做出来的东西，只要他不甩屁股丢给别人，应该有他受的，经过很长一段时间后，他还会像当初一样激情么。
10 楼 wupuyuan 2011-11-22 我觉得“可控性”等软性指标，不仅仅归纳在程序员里。而是各行各业的人成为优秀者必备的能力。不同行业的人所需的技能是有交集的。呵呵，难得来踩一下！ 11 楼 langyu 2011-11-22 wupuyuan 写道我觉得“可控性”等软性指标，不仅仅归纳在程序员里。而是各行各业的人成为优秀者必备的能力。不同行业的人所需的技能是有交集的。呵呵，难得来踩一下！
呵呵，欢迎璞渊兄来访。可能大家怀疑的地方在于可控对于程序员的创新是不利的。
