一年后再读《rework》

为什么80%的码农都做不了架构师？>>>   

在kindle里面买的第一本电子书是《rework》，当时难得一气呵成地读完，像找到知音一样的快感。一年后，当我再次把当年kindle上的标注温习一遍的时候，发现读后感与当时大有不同，不知道这是叫成熟还是叫终将成为自己讨厌的那种人。

忘了“现实世界”

“这在现实世界中完全行不通。”当你向人们介绍一个新创意时，人们总是这么说。

这个“现实世界”听起来如此令人沮丧，貌似所有的新创意，新提案以及外来概念总是会在“现实世界”中碰壁。在这里，能够立于不败之地的都是那些人们耳熟能详，习以为常的事物，即使这些东西已经漏洞百出或陈腐低效。

一年前对这段话感觉特别带感，那时候总决定自己的想法都是创新的，都是颠覆的，别人都看不懂我的世界，那一定是别人都在拒绝创新，拒绝颠覆。现在，回过头来却发现自己逐渐成为了维护这个“现实世界”的人。

在公司里的项目是一个HTML5的混合应用，以前没人做而我做出来了，感觉这个东西很超前，很创新，不但应用了最新的技术，还非常节省成本，老板也很接受。往后的时间里，但凡有人提出原生开发的意见我都报以拒绝的态度，依据就是原生开发的成本太高，而且不便于维护两个版本，对于追求压缩成本的“现实世界”而言根本不可行。最终，公司在最近一个项目中，客户声明要求原生开发，最终成为我们项目组失去参与此项目的机会的原因之一。

我，真的变成了那个曾经让自己感觉讨厌的维护“现实世界”的人。

当然，HTML5这种形式，本身没有错，在一些场景下是有充分的价值。我的问题是，一直死抱着这个方案，不愿意尝试不愿意改变，心态上变得过于保守，而失去了机会。

着手做点什么

在你的人生中真正有意义的是你做了什么，而不是你想过什么，说过什么或者计划过什么

所谓成王败寇，不光是你做了什么，更重要是你做成了什么。系统做出来了，收益呢？市场呢？前景呢？都看不到，那还是一边凉快去。还计划反馈开源社区，只能想想罢了。

作出决定就是取得进展

做多少计划不重要，人总是难免犯错。不要因为事前的过度分析和犹豫不决而把事情搞砸。项目周期过长会打击士气。项目开发时间越长，成功的可能性越小。只要有足够的动力和士气，就要趁热打铁，积极决策，果断推进，现在就把事情做出来。

我一直反对什么年度计划。要是能对一年的事情有先见之明，那我觉得我一定成仙了。所以我更偏向年度目标，月度计划。一年里，总得有个目标，有个方向，有个盼头，团队朝这个方向前进，向这个目标努力，也就是所谓的愿景，也类似一种精神寄托。但要细化到具体的计划，时间跨度不宜过长，一个月属于比较靠谱的范围。可以看到很多敏捷团队的迭代周期也差不多在两周到一个月左右。

但是光有目标，没有计划，确实是会令项目组的士气受打击的。我们最近做的一个版本迭代，开发了一个月，测试了一个月，上线又折腾了半个月。等折腾过来后，好像都不知道往后要怎么走了。

质量为王

这与产品包装，市场营销或价格无关。在这里质量为王。

决定因素

业余摄影爱好者总为使用胶片相机还是数码相机而争论不休，却没有人关注拍出绝妙的照片的决定因素是什么。

很多业余高尔夫球手执着于加入昂贵的俱乐部。但是真正重要的是如何挥杆，而不是加入哪个俱乐部。 我以前看到别人随便就挂个单反，也想吐槽一下：不是有单反就能照出好照片。但实际上，我作为程序员的时候也经常为自己用vim而感到自豪，也会轻视用eclipse的同事，按之前的逻辑，用vim也不代表会写出更好的代码。那应该怎么看待这种追求和自豪感呢？所谓工欲善其事必先利其器，当你处于一个专业领域的时候（哪怕你只是业余入门），其实首先都应该选择一个最好最适用的工具，以求帮助你达到最好的使用效果。对工具的追求其实也是你内心对此专业领域提升的一种坚定的暗示，使用高大上的工具并不会令你马上有获得提升，但是会让你在提升的路上变得更坚定，而且更快。

现在很常提到一个名称叫圈子，俱乐部也就是一种圈子。其实圈子和刚才的工具是一样的，加入圈子，并不是代表你就跟那个圈子的人一样等级一样水平了，而是通过加入圈子，形成积极向好的心态，并且通过向优秀的人学习，最终帮助你在提升的路上变得更坚定而且更快。

立马就上线

当我们推出Basecamp软件时，连收费功能都没有完成！因为这个产品是按月收费的，我们明白还有30天的空档期可以用来完成这项功能，于是我们把宝贵的时间用于解决更紧迫的，上线当天就得解决的问题。而30天后才需要用到的功能，可以再等等。

赞同的错觉

商业世界中充斥着各种无用的文件，这些文件除了浪费人们的时间外，一点意义都没有。没有人读到报告，没有人看到图表，无法完成的细则。这些东西做起来颇费工夫，但是人们一回头就能把它给忘了。

如果你一定要说明某事，那就务实一点。不要描述它长什么样子，直接画出来；不要解释它的声音如何，直接哼出来。要尽一切可能去掉那些抽象的东西。

甘于低微

一旦你把事业做大，深入人心之后，就不可避免地要走稳健路线。当你成为传奇人物，你的变得更为保守，更难去冒险。这就是僵化的起点，变革的终点。

在现在这家公司，我是从零开始，所以一开始大家都轻视甚至无视我。我还记得上班第一个月看到隔壁部门经理时候，他对我的态度，不屑一顾。那时候的我虽然弱小，但是无顾忌，抓住一个机会就迅速做大。别人的态度变化是很明显的。但风水轮流转，系统的用户多了，累赘和顾虑就多了，一次版本升级出了bug，就换来一堆投诉；一个不小心生产服务出现故障，更被有心人揪住来打击你。然后各种报告，各种措施，最终结果是你不敢轻举妄动，宁愿少做事，总比做错事好。跟书上说的，一模一样啊。

常规教育不值一提

我从来不把我自己受过的正规学校教育等同于我的受教育程度——马克吐温

人人都得干活

在一个小团队里，你需要的是干活的人，而不是监工。每个人都得做事，没有人可以袖手旁观。

这就意味这你在招聘中要避免招到监工型的人物，这些人喜欢对别人循循教导。对于小团队来讲，监工型的人就是累赘。他们想出各种事情让别人去做，在丢下自己的工作去安排别人时，他们制造出了更多的工作——不管这些工作是否需要去做。

过去我最讨厌监工，他们不编码，他们就指挥我编码。我觉得一个公司，这样的人除了老板，就不要再多一个了。

随着团队的壮大，随着职位的晋升，我逐渐发现如果我还继续编码，项目真的推进不下去。我们始终无法像google，facebook那样，招到最好的工程师，团队的组成大部分还是经验浅的新人，素质也很难保障。有的成员，技术不错，但是喜欢偷懒，安排一件事做完了就算了，就自己去看其他东西了；有的成员，理解能力不行，安排一件事，做出来的跟设想的出入太大，根本不可用；有的成员，没什么方向感，很容易不知道自己应该做什么，然后开始迷茫……如此种种，当我埋头写了一天代码后发现，其他人的状况都很不妙。再过几天，项目已经开始溃烂。这时，我不得不做起监工。我需要每天跟踪成员的工作内容，能者多劳；我需要验证确认成员提交的代码符合最初的设计；我需要提醒成员知道每天需要做些什么，需要在什么时候交付些什么；我还需要做更多，比如版本规划，比如架构设计，比如团队内外沟通，比如写各种文档。真的，无法再每天写代码了。更无奈的是，我逐渐从写不出好的代码，到了写不出代码。

员工不止13岁

接下来我们再谈谈你要花多少时间和金钱来监管员工。安装监控软件得花多少钱？IT员工得浪费多少时间去监控员工，而不是去做更有价值的实用项目？你浪费了多少时间去写无人看到规章制度？看看这些成本，你很快就会意识到：对于员工的不信任才是最大的开销。

转载于:https://my.oschina.net/fwj/blog/365344