第一次思考这个问题是在微软顾问咨询部的时候。当时我们讨论的问题是：测试是不是做得越多越细越好。有经验的顾问分享，从高层次这是一个业务问题，而不仅仅是技术问题。按照火星探索车的测试要求测试普通自行车是可以的，但是这辆自行车可能没有客户买得起。这个讨论，测试是不是应该太强涉及到。

    最近在创业的过程中，也有类似的感觉。对于任何事情，不见得做的最好就是唯一的正解。在微软这样的大公司，任何事情都要追求卓越，因为大公司里，资源常常不是最紧缺的资源，同时公司的平台足够大到任何一点的改进都会有比成本大得多的回报，而一点点疏忽就可能搞砸整个计划。比如在微软准备PPT，台下基本上都是几百人到上千人，容不得一点差错。而小公司的时候，错了的影响没那么大，而有的资源(无论是时间，钱)都小的多。

    程序员也有类似的转变。最典型的就是Java程序员开始用PHP编程的时候那种不适应。凡是用C++或者Java编过程序，尤其是钻研得最够深的，看到PHP那种没有变量类型，没有命名空间，上来就直接写页面的方式，常常不屑一顾，写起来也是老大的不情愿。原来的5年积累起来的构架的能力，在各种Framekwork里面游刃有余的能力，还有严谨的分层和复用的能力，在PHP的世界里面变成了累赘。尤其在自己还没有把基础的类搭好，隔壁的PHP程序员已经发布了能用的(虽然是恶心的)版本，那种不服，却不得不服；有一肚子的话要说，却找不出什么可以说的苦恼，估计经历过的人，都会心有戚戚焉。

    面对这种情况，我的建议是，保持足够开放的心态，去适应新的环境。还以编程为例。当自己熟悉Java的时候，我们是站在A点。当我们学会了PHP的那种思路的时候，我们并不是从A挪到了B，而是站在了比A和B高得多的C点，一个可以在两种思路中间游刃有余，自由选择，没有个人偏向，而仅仅是根据不同的情况选择合适的方法的C点。

    我们学会的东西就是一味一味的草药。当各种药都会用了，我们才会对症下药，而不是因为自己会用那种药，就给所有的病人吃一样的药，然后对吃死的病人埋怨一番，说他不懂自己的药的好处，说自己的药是好的，要不是这个病人虚火太重，我的药一定药到病除。