Michael Chen's Blog

感同身受

Fri May 11 00:00:00 -0700 2012

自从开始做产品之后，我就成为了产品运营人员的一部分。每天，我与行政收到同样多的邮件。出差请求，感谢，抱怨，我都一一看在眼里，记在心里。得益于之前出了无数的差，因此对于出差人员的感受非常直接，然而在行政这边，估计许多人如我一般，对她/他们了解甚少。与程序猿不同，她们（多数是女性）的时间被扯得稀烂，最新来的事情优先级最高。她们善良体贴，乐于帮助他人，一点点的工作失误自己会难过得不行，而来自同事的称赞则能让她们高兴好久。

这种真实的体验让我对产品与用户之间的距离有了更深刻的理解。产品还在试运营。一天行政苦笑着跑来找我：网页出错了，500 Error。我立刻几乎可以想象，她正在使用着软件，点着界面，突然之间这个恐怖的、白色的、带着几行红色粗体的错误信息页面出现在面前，对于一个没有任何编程经验的用户，是多么恐怖的体验。一种无法解释的内疚油然而生，我看着她说：对不起，理解你的感受，我马上修复。

她楞了一下，迅速说：没事，不着急。

几分钟之后修复好了。她在IM上回复说：太感谢了！

这些让我对软件的价值重新考虑。我们需要真正的使用这些软件，才能够得出真正的体验，并能够在使用不便、出现问题时真正感同身受的说：说：对不起，我理解你的痛苦。我们正在修复。

很多软件忽视这个过程。软件的设计者、制造者、销售者、客服与用户之间，通过各种部门、KPI隔离开来，然而又妄图通过各种制度来标准化服务流程。可惜，销售者不用自己的软件，客服也没用过自己的软件，制造者根本见不到用户使用的样子，又如何能够真正体会用户的感受，制造出贴心的软件，提供贴心的服务呢？

2000行代码

Tue May 01 00:00:00 -0700 2012

早在写《架构腐化之谜》的时候，我就意识到，造成架构腐化的根本原因是系统复杂度变大的必然趋势以及人类遗忘的天性。延缓项目腐化最好的方法，是根本不给腐化的机会。生活中，自然通风、阳光透亮、家具摆放合理的、不留死角的房间出现虫子的可能性很低；代码也一样，一份简单、符合直觉的代码，放在复杂度完全可控的代码库中，能够极大的降低学习的门槛以及避免腐化的可能。

包括自己在内，很多人当然以为这只是美好的想法。绝大多数开发者仅仅能尝到项目早期的甜头，在后期则进入了愈发沉重的深渊。对于文中所说的似乎只是一个遥不可及的想法。为了证明这个是否真的可行，从去年10月开始，我在自己的产品中进行了一个尝试：在保持功能正常增长的前提下，项目总体功能代码不超过2000行。

现在是什么情况呢？从去年10月到现在，git统计数据如下

414 files changed, 42824 insertions(+), 698 deletions(-)
430次总共提交
Code LOC: 1568     Test LOC: 799     Code to Test Ratio: 1:0.5

功能代码总共不超过1600行代码（当然未包含大量的CoffeeScript以及HTML/Sass代码），完成了大部分的核心业务逻辑。未来可见的功能也应该能够在400多行的空间里完成。系统中也存在不少能够提取为独立Gem的地方，可以继续进行隔离简化。

应该说得益于Ruby简洁的语法，以及在rubygems社区提供的各种高质量的gem，让以前不可想象的麻烦变得几行代码就能搞定。

我们得到了什么好处？今天新加入了一名程序员，花了点时间介绍产品背景之后，在不到2个小时的时间里，就完成了一个典型的功能。并且还顺带修正了一些代码上的Bug。

Rails固然是特例。但推广到其他的语言，只要遵循以下原则，应该是毫无问题的：

Don't Repeat Yourself - 绝对不要重新发明轮子。github上fork数量多的项目基本上已经相当成熟了。即便有问题，fork, fix, pull request的响应时间比以往任何一种方式都要迅速，还能回馈社区。
遵循约定，遵循约定。在某个时候总忍不住自己写了类似于get 'cities/edit'在routes.rb中，但随着类似的代码越加越多，最终索性就变成了resources :cities. Rails是经过许多工程实践的框架，其中的最佳实践很多时候是经过验证的。对于其他技术框架也应该一样。有时候发现了异常情况，不要为这种异常情况特殊处理，约定化也许是更好的方案。
隔离，隔离。凡是与核心业务无关的功能代码，在找不到开源替代的时候，想办法将其通用化。比如我们用到了解析openflights的机场数据。这部分与核心业务毫无关系，将其隔离为Gem，再引用，能够减少无关代码干扰，形成知识分界，对于专注了解系统有莫大好处。
警惕未经使用的功能、代码、注释、甚至数据库字段。保持代码库总在最精简的状态下。

这个产品已经上线。在可见的未来，2000行的界限还是够用的。等到超过的那一天，我再写写看看。也许那一天可能永远都不会到来。

与真实数据一起工作

Thu Apr 26 00:00:00 -0700 2012

大约几个星期前，同事找我帮忙看看一个关于类似于TODO/Action的手机UI如何设计。看到他们的正在工作的界面之后，我完全没有感觉：在TODO List界面上，零星的放着abc, def, dfsg之类的随意字符；顺着链接点进去，里面放着的是完全无法建立情感联系的blabla文字。我完全无法想象如何在这种场景下进行UI设计——软件本身只是生硬冰冷的工具，用户贡献的数据才是血肉之源。数据被粗心的对待时，作为开发人员你与用户之间基本失去联系。这种状况下我们如何能最起码保证设计是贴心的？

之前在自己开发的个人项目中也有不少需要用到人名的情况。当然不会采用类似于ABC之类的随意字符，但仍然采用了类似于张三丰、任盈盈之类的名字。发布之前用户都笑了：这是什么啊。把名字换成类似于李键、赵文斌（如有雷同纯属巧合）之类的名字之后，用户开始更为慎重的对待这个系统。

设计师在这方面做得很好。他们会很耐心的抽象出一些典型的用户（Personare），取个典型名字，放到真实的业务场景中，所用的词汇和数据看起来几乎跟真的一样。而程序员则在这方面疏于修炼——大多数仍然满足于仅仅将功能完成。一些更为惫赖的公司则索性把开发阶段的产品截图放到自己的产品介绍中，随处充斥着客户姓名是张三、一张机票100.00元、留下了一段内容是abcd123的留言等等截图。用户在看到这样的粗糙的车间半成品的时候，他们如何能够想象这个软件能够与自己真正的业务过程集成呢？

软件是给人使用的。从软件构建到软件递交到用户手中的时间应当越短越好。真实数据——作为最直觉、用户应该最关心的部分，却经常被开发人员忽视，而这部分是开发人员最直观了解用户如何使用系统的途径。如果你无法想象真实的数据，很大程度上意味着你根本不了解你的用户。

PS. 在准备给学生的作业中，我专门查找了国家农产品的价格数据库，以及最近的购物小票，以期给学生更为真实的开发体验。构建计算机思维与自然界的联系，构造更有用的软件，从身边的数据开始，应该是最简单的切入点吧。

忘掉过程

Tue Apr 24 00:00:00 -0700 2012

透明度似乎成为越来越重要的一个目标，特别是在做咨询相关工作的时候。目标？计划？阶段交付产物？是不是保持持续的沟通？

在我从事咨询的过程中，这些问题一直困扰着我。在从事离岸开发的过程中，也存在各种的报表、邮件、日常的交流。会议和谈话占据超过实际工作的30%的时间似乎是一件很正常的事情。

这并非有什么不好。持续的反馈永远都是重要的。有时候客户买的，并非仅仅是最终的交付产物，在交付过程中的一言一行，能够给客户莫名的信心。想想小时候你花着几毛钱等着大叔给你做糖人，那糊糖人的过程与最终拿到糖人的喜悦，很难分得清哪个更重要一些。

很多公司很看重过程。“没有功劳、也有苦劳”便是其中的典型。即便最终结果不好，过程中尽力了，也算是可以理解的。然而当产物可能产生更大的影响范围的时候，这条规则便行不通了。

一个粗劣的软件——比如那个火车票网站，很可能是从业者起早摸黑做出来的，那有怎么样呢，它给几十亿人带来了痛苦；一个最终看起来很山寨的网站，你仍然可以呕心沥血的说，经过长时间的抉择，采取了这种方案，但用脚投票的用户根本不会买账。相比较而言，对最终受众的有针对性帮助，真正做出兼具艺术美感与人文关怀的产品，人们自然会从产品中体会到设计者的良苦用心（甚至不可言传）并自发的成为拥护者。

这条规则放在办公室运营的时候，如果过于注重过程，则会产生无数雷声大没雨点的动作。比如，今年目标是5000万，那么我今天招了多少人，明天内部做了多少培训，后天等等等，把这些动作敲锣打鼓的发扬光大，固然显得动作不小，最终即便失败，似乎也显得说得过去了。

当受影响的受众超过一定规模的时候，忘掉对过程的过度宣传吧。只有受众真正接受产品之后，他们才会对产品的制造过程产生兴趣，否则只能沦为另外一个毫无意义的失败案例。

致设计师（募）

Mon Apr 16 00:00:00 -0700 2012

许多人从小都喜欢捣鼓点东西，写写画画，泥巴做的玩具，拆掉又装上的收音机。一些人很幸运，成长之后一直忠于自己的兴趣，最终成为满足体面生计的职业。而大多数人则在父母、教育制度、社会压力三阶段压力之下，沦为职业系统的砖瓦，从此过着朝九晚五的日子。

关于设计师的印象，在我心中却从未变过。小时候看过父亲晒的蓝图，那一根根清晰的蓝色线条下对应出的房屋建筑，透露着说不出的美。没去多少次的公园，参天古树与顺势而建的各种园林，也让人有种说不出的美。这背后自然是设计师的功劳，我明白这一点时已经很晚了。

然而设计师也逐渐沦为职业系统的产物。第一次对这个有印象，是在大学期间承接的一个政府项目。项目快上线了，于是有了非常中国特色的领导视察。站在旁边，领导用肥嘟嘟的手指着屏幕，说，喏，这块，用红色，那块，用蓝色。我看这个字有点小嘛，改大点。伴随着旁边一堆的叫好声，你捏着鼻子默默的改掉这些，然后再也不看第二眼。

第二次对这个有印象，是在第一家公司，新招了一个美工。那个时候我已经喜欢自己做界面了，但也仅限于用HTML/CSS来重现软件界面。听说来了个MM美工，很是高兴，于是颠颠的跑去，看看能不能学到一招半式。我去的时候美工很忙，忙着把公司网站加个新闻，改个样式，印个说明书。后来去的时候还是很忙。有一天我在她旁边看了很久，发现她只用Fireworks把图片切成圆角，然后嵌到HTML Table标签中，FTP到公司网站就完事了。有时也会从网上弄点转来转去的Flash，用盗版的Flash软件把里面的文字改改，也继续传上去了。

很失望。

人们说，生活中不是缺少美，而是缺少发现。而我认为这是屁话，生活中就是缺少美。比如我一次又一次的诅咒东直门机场快线脑残的设计——明知道都是有行李的人，候车站台只有2米宽；车厢里走道像飞机一样只能一人并行；西直门如同迷宫一般令人绝望的各种换乘；西安新软件园那个极其山寨的、用红色的隶书写上的XXX商务酒店；至于在中文互联网领域，飘来飘去的广告，密密麻麻的链接，毫无设计的配色，这些都令人深深的怀疑。生活中就算有美，也是少得可怜。

而我相信，背后的一切，是有设计师的角色存在。或者他们被毫无品味的老板指挥者，或者他们被无数的工作堆压着，或者他们妥协于某个委员会；或者他们本身，只是听说设计师挣钱，机械的完整了这些工作。仍记得03年开始去北京闯荡，那时各种IT教育机构叫嚣着，来XX培训，年薪10万！如今房价都已经翻了好几番，CPI翻了好几番，他们仍然叫嚣着：来XX培训，年薪⋯⋯还是10万！软件行业如此，设计行业料想如是。

而我坚信一些东西。

美工只是一个阶段，不是一个职业。重复对于设计师而言是不可忍受的。设计师持续追求技艺创新，除此之外，还承受超于常人的生活体验与情感体验，从而产生出充满人文关怀的设计。那些流传悠久的设计从体现出来的人文情怀，是设计师对真实生活不断反思锤炼的结果。优秀的作品一定是对外的，除了视觉上的美感，作品所传达的意图应当充满灵魂，代表了设计师自我与社会的融合。

这是职业化的对立面。职业化恨不得将这个原本完整的过程拆的零碎，从而产生更多的头衔和职位描述。美工，初级设计师，高级设计师，设计总监；界面设计师，工业设计师，交互设计时；广告设计，平面设计，动画设计等等。职业化固然有存在的必然，但我仍然相信这些只是阶段，而非一辈子的标签。追求美，追求品味，追求极致的设计，是区别设计师的关键。

目前我在设计一个新的基于Web的产品。他们把这个角色命名为产品经理。我也在写代码——他们命名为程序员；也时不时要查看系统日志，看看是否运行正常——他们称为系统管理员或者网管；也需要听取用户的反馈，解答使用问题——他们称为客服。并不在乎头衔是什么，这些工作的目的是制造伟大的产品，为数以万计的用户提供服务，而在此之前这些用户要忍受昂贵、粗糙、丑陋、低效的软件工具。我需要帮手，一个真正的设计师。如前面所说，你需要具备高超的审美和Graphic Design技能，不轻易妥协。目前状态下，具备软件界面设计/Web应用设计能够立刻与团队一起工作，但如果你设计能力非凡，学习能力飞快，你会有充分的空间来融入团队。我理解审美是长期修炼的过程，因此你最好拥有多年的经过证明的设计经验，我不是学历的粉丝——早就见过因为艺术可以减分考大学的突击两个月学画画的了。

你参与的软件将会改善数万人的生活。你会与顶尖的程序员一起工作，他们会与你讨论甚至争论，但他们最终能够实现你的任何设计。你会使用最大屏幕27" Mac电脑。你会体面地使用正版软件，包括昂贵的Photoshop。你会拥有充分的设计空间。不必朝九晚五，虽然偶尔需要工作很长时间。

最后，最值得一提的是，你的名字，与其他程序员一起，会被显眼地写在这个即将改变数万人的软件里。

想要充分的设计空间，想要改变这个世界，请给我发邮件：mechiland@gmail.com

做，然后忘掉

Tue Apr 10 00:00:00 -0700 2012

突然之间成绩来的容易起来。看过的书，走过的路，去过的地方，成功的项目，克服的困难，曾经的荣耀，似乎一切都都变成谈资，饭桌上，咖啡厅里，大脑的回声中，这些旧事，成就也罢，痛苦也罢，不断的被提起，经过记忆的润色，居然散发出神奇的，令人沉醉的遣眷气息。如果接着来上一点对现在的嗟叹，则显得更妙了。恨不得整个人都窝进椅子里去，对这不堪的现实继续吐槽。

而时间则无情的往前滚动，既不曾轮回，也不曾转弯。那些曾经不起眼的人，悄然之间，或自己主动，或被时代冲刷，逐渐成为无法直视的巨星。也许在闲时，大人物们也有槽要吐，或有得意之处少不得炫耀，但终究那些在脚印旁边绕圈圈的人们逐渐销声匿迹，而做了，忘掉，接着做，往前看的，他们自己都不会意识到，风霜磨砺之间，众生的眼光已经充满崇拜。

内心再丰富，想要对这世界有些改变，却终究是要追求外部影响力的。世界无法钻到你的内心，它只能看见你的对外工作。做了，等待着世界给你反馈，就像在世界里画了一个浅浅的点。在等待的时间里，慌张，犹豫，揣测，终究停下来；而时间在身边如风般呼啸而过，浅浅的点痕迹逐渐淡了，最后消失了，人们甚至不会注意，这个点是否真的存在过。

做，忘掉；然后继续。在追求的过程中被推着、主动跑着前行。身边错过的风景，其实才是奖励。你留给世界的笔迹，才会渐渐如刻刀，留下更为长久的痕迹。

油菜花

Thu Apr 05 00:00:00 -0700 2012

仲春初夏，是油菜花盛开的季节。黄灿灿的油菜花，在春天的暖风中如浪般涌动。微风的时候，如同黄色飘起的缎子，渐渐飘远；疾风的时候，油菜杆随着风向摇曳，向远方看去，如同起伏的海浪。

窄窄的阡陌交纵，不仔细看，很难区分这大片大片的油菜是被隔开的。这个季节却是孩童们的最爱。身高只比油菜高出些许，稍一蹲下便看不见。捉迷藏自然是最受欢迎的游戏。下午放学之后，阳光尚好，春天的夕阳依然柔和，运气好的话还能看见天边如鱼鳞一般层叠的云朵。而孩子们自然是不会注意这些的。夹着几乎细不可闻的花香，畅快呼吸的春风让他们在田间疯跑。总会丢掉一些东西，铅笔，橡皮之类，回到家会挨骂。也有时候跑的兴起，把跑得慢的女生一直撵到邻村去，自然也少不得一顿训斥。似乎很快就会忘记，第二天如同什么都没有发生一样，继续疯跑。

村子很小，基本上大家都互相认识。这个时候来的神秘养蜂人引起了小孩子极大的好奇心。养蜂人住在自己的帐篷里，小孩子自然觉得这是一件威风得不得了的事情。他还随身带着数不清的木头箱子。至于里面是什么构造，小孩子从来都不会知道。只是发现，在阳光灿烂的时候，蜜蜂多了起来，仔细注意的话，能够看见油菜花上的小蜜蜂，不知道在忙些什么。附近的村民偶尔到养蜂人那里，聊聊天，扯些家常，走的时候带一小罐头瓶新鲜的蜂蜜。蜂蜜自是极为珍贵的东西，趁大人不注意，偷偷拧开盖子舔一口，那芳香甜味，一直沁到心里去。

二十多年过去了。

城里人了解油菜，似乎更多是去了餐馆。大多数分不清油菜与油麦菜之间的区别，也看不出来油菜和小青菜之间的差异。突然之间看油菜花成为一种时尚起来。纷纷在这个时节冲出城市的阴霾想要去看一看，结果他们看得最久的是秦岭的隧道，和前面无尽等待的汽车。

那些简单的幸福似乎再也无法得到了。骄傲的人类认为了解了所有的知识，迫不及待的向世界张扬着自己的足迹。而那些触手可得的垂青，如今变得不可思议的昂贵。淡雅纯真的花香，沁人肺腑的春风，晒得发疼的阳光，这些，又在哪儿呢？

我如何学习：索引

Sun Mar 25 00:00:00 -0700 2012

磨磨蹭蹭终于写完了这个系列。本文算是为1-6做个索引，也做一些注解。从个人体验来说，这类纯粹从个人角度出发的学习心得很难为读者提供实际的指导作用——类似的提升肾上腺素的文字也有很多的。但所谓教者谆谆学者诺诺，追求个人卓越的道路总不止一条，只要路上没有浪费太多时间在做无谓的事情，每个人总能找到自己独一无二的路径而不用在别人的车辙里挣扎。

我如何学习系列索引

跟随好奇心 "生活并非是一个非此即彼的选择题。追求一个完美解只能让你功利并狭窄的阅读、跟随那些有限的足迹。而世界在变化，等真正明白自己所需时，搞不好时代已经过去。引导你进入学习的，不应该是责任、压力任何外在的东西，应该是你的好奇心"
不要停 "刨掉一半左右的水分，大概是10万行，平均下来每天都写100行代码，365天不停的，写了三年"
以美之名 "我们内心知道，有更好的东西。但这种诉求却常常被妥协。直到，我们真正见到美好的东西"
对手不在身边 "但如果你不幸的待在一个在你看来周围人速度慢的像乌龟一样的团队时——处于种种原因你还不想离开——幸运的是作为软件从业者，你的竞争空间，永远是全世界。你有无数种方式获取最新的技术知识，也有极其廉价的手段将自己的知识发布出去"
超越，或者创新 "一旦你开始抄袭，你就被抄袭对象牵着走了。任何时候你都被挂着复制者的影子"
拥抱冲突 "当冲突来临而自己又没有处理好的时候，实际上是一个信号，意味着这方面能力的欠缺。无论这是什么，不要逃避，不要迂回，等冲突那一刹那的情绪过去，冷静下来，仔细考虑自己到底缺少什么"

需要一些理性的判断才能获得这些文字真正的观点。比如，跟随好奇心——当然并非随时随地都要的；不要停——当然是要保持基本的生活兴趣工作的平衡；以美之名有太多的主观性，但艺术修养是基础；至于拥抱冲突——你不至于想尝试取悦每个人吧。

我如何学习6：拥抱冲突

Fri Mar 23 00:00:00 -0700 2012

2009年的春天，我在新加坡，为上线前最关键的特性——Single Sign On(SSO)集成而做着调试准备。本应该很容易的工作，却由于遗留系统而测试了6周。可以想象的业务部门与IT部门之间的隔阂也产生了许多额外的工作量。最终确定了问题的大致所在，但我们自己无能为力，需要IT安全部门进行一个服务器的配置。于是一个周五上午，我将问题描述、可能采取的应对方式写了一封邮件发给了他们的主管。

本应该是一个很自然的事情。

快下班的时候，客户PM接到了电话，说了没几句，面带同情的把电话给我，说IT主管要找你说话。接过电话，还没来得及忐忑，电话中就传来了带有印度口音的咆哮声：are you stupid? ⋯⋯更郁闷的是，我居然没有全听懂。等他说了几分钟之后，我也不爽了，一字一顿的跟他说：我会告诉你哪里出错了，然后挂断电话。

客户PM同情的看着我，摇了摇头，意思是他拿这个人也没办法。

然而事情还是要往前走的。周六我重新把出问题的地方重新梳理了一遍，将出错的场景、预置条件、重现步骤、相关截图和日志整理成了一份份排版良好的文档，再一次发给了他。与上一封邮件相比，信息类似，不过更加的明确与清晰。

周一的时候收到回复：这就是我想要的报告！后面居然还有个笑脸符号。

这件事情之后我再也没有让这类事情发生过，不论是美国的还是澳洲的。有时候冲突来的莫名其妙。尤其是自己怀着一番好意进行往前的时候，得到对方几乎毫无保留的反对。羞愧，郁闷，愤怒，鄙视都是可以理解的，认为对方是SB也是许多人的态度。但不论如何，无法改变的事实是，你不能理解对方到底在想什么，到底为什么要反对，以及在这种前提之下达成双赢局面。换句话说，这方面的能力是欠缺的。上面的例子有点极端并不算太好，工作中这类例子却比比皆是。自己辛辛苦苦做出的成果不被重视？在讨论中过于坚持自己的观点被喷的体无完肤？这都是冲突，有些在明处，有些在暗地。

冲突与学习有什么关系？冲突很大程度上是用来检验学习成果，也能过用来提升学习能力。打算开始健身？跑了没几步就气喘吁吁，这是你想健身的意愿与实际体力产生了冲突，说明你体力不足；好不容易迈出步伐到了客户现场却为一些基础的东西争论不休，这是你的实际能力与意愿能力产生了冲突。一门心思埋头写代码，面对同事在架构上的问询争得面红耳赤，则要么是自己没有想清楚，要么是自己说不清楚。

如今的社会个体越来越需要依赖外力才能获得进步。沟通的能力也许是与专业技能同样重要的能力。当冲突来临而自己又没有处理好的时候，实际上是一个信号，意味着这方面能力的欠缺。无论这是什么，不要逃避，不要迂回，等冲突那一刹那的情绪过去，冷静下来，仔细考虑自己到底缺少什么，然后直面它，锻炼，直到你获得了这个新的能力。

相关链接：我如何学习全系列索引

最后一根稻草

Wed Mar 21 00:00:00 -0700 2012

不知道有多少人知道插秧这个农活。小时候，面对着一亩多地的水田，我跟弟弟一弯腰就是整个半天。凌晨4点天蒙蒙亮就开始，8点左右吃点东西，到12点。躲开太阳最毒辣的12点到2点，正好打个盹，然后2点多继续，一直到天慢慢黑。忍耐力就是那个时候形成的吧。然而最令人痛苦的并非是不断重复弯腰的过程，而是在接近完成的时候，似乎觉得剩下的那么零点几分的水田，永远也插不完。身体的疲惫，似乎在接近完成的时候变得越发的无法承受。

有许多描述这种感觉的例子。产品要发布的了，却发现剩下的工作却似乎越来越难；期待着马上营业时间结束了，却来了一个不怎么待见的客户；马上要休假了，却发现要处理的事情显得越来越复杂。于是开始烦躁，开始无法承受，开始有了一些出乎意料的举动。比如，本来还算顺利的开发过程在最后那么一刹那出现了许多无法控制的问题，直接导致加班，加班，加班；本来已经疲惫的神经终于在面对最后一个顾客的时候忍不住态度恶劣开始发火；本来顺利可以休假的却发现还有些事情记挂不下走的也拖泥带水。

看起来像是压垮骆驼的最后一根稻草。从旁观者看来当然很明显，有分量的不是最后一根稻草，而是前面的更沉重的过程。为了冲刺过分透支了前面的精力，在需要冲刺的阶段反而不给力。我们作为人类在计划与估计上的过分乐观几千年来就没有真正改变过。所谓“近乡情更怯”，并非是靠近村庄才更忐忑，而是数年离家在外的游子情的堆积，终于在近乡的一刻才爆发。

想要不被最后一根稻草压垮，说的庸俗一点就是要有平常心；说的技术一点就是要做任务分解。一个巨大的成功固然令人欣喜，与此随之而来的巨大的失败也令人沮丧。将两个星期的计划变成两个一周的计划；或者4个三天的计划。想象自己就是那苦命的骆驼，面对着成吨的稻草，一次能够运过去显得很厉害，但更可能得到的评价是冲动和愚蠢。分几次运过去不那么激动人心，但假以时日，只要不停，总能完成的。