是这样，这几天，从美国那边过来几个比较有经验的同事，因为相对来讲，中国这边的团队比较年轻，因此安排了一个“Open Forum” 的讨论会，让他们与中国的同事分享一下成长经验。他们一个是中国人，清华硕士毕业后去了美国，有10年的工作经验了；一个是美国人，有20年的工作经验。

  其间有一个人问了个问题：“要成为一个比较资深、优秀的技术人员，你觉得什么是最重要的？” 这两位同学给出了看法基本一致,概括起来就以下两点：

• Don't treat the code you not own as blackbox
  每个人写代码，其所涉及的方面不仅仅是你所”负责“的那些模块，你往往需要从整个系统的层面来考虑问题：我所依赖的那些模块是怎么工作的，怎样正确的使用他们？怎样高效的使用他们？ 以及谁依赖于我，我的改动会对后续模块产生什么样的影响，等等。听起来蛮简单的一个道理，但要做到其实并不那么容易。尤其在一个有几百的模块的大系统中。很多人的工作方式是直接发封信去问那个模块的owner或者expert，的确很"高效"，但是如果你需要长期在这个系统中工作，你需要经常接触这些模块，那么最“高效”方式恐怕是你好好研究一下这些模块，搞清楚其组成与工作方式，所谓磨刀不误砍柴工。不要认为这与我没有直接关系就可以不管，将其看成一个"blackbox"，其实在程序员面前，只要你愿意，什么都是“whitebox”，任何程序都没有什么magic，只是以最简单的规则与逻辑组合起来的东西而已。
  而最关键的是，只有这样，你才会进步，你才会渐渐成为某一领域的专家。不然，正如你所注意到的那样，有些人在干了N年之后，问他整个系统是怎么工作的，他都说不出个子丑寅卯来。
  
  
• Don't assume, just confirm
  假设害死人，害死你自己，或者害死别人。举两个例子：
  1. 在调试程序的时候，我们经常会做了自以为是的假设：注册表应该没问题吧、DLL数据的初始化也不会出错的，那么会是消息传递出错了吗? 好像也不会~~~。 我们一直在思考，却不去求证，而这所谓的思考，就是假设，然后在自己错误的假设下愈行愈远。这是害死自己。
  2. 作为某一领域的权威，人家发信问你个问题，你不太确定，于是回道“我觉得”应该是这样，或者应该是那样，然后人家照你“觉得”的方式试了一天，不行，然后和你说不灵，然后你再“觉得”一下，继而又浪费人间一天时间。这是害死别人。
  其实为什么要做这些假设呢，你完全可以停下来，花个5分钟或者10分钟去确认一下，不就什么都ok了？一步一步踏踏实实往前走，才是真正的往前走，依靠在那些浮云般的假设，你始终都在摇晃。而且，正是这一次次的确认，才构成了你真正的经验，不然，若干年后，你有的只有自己的假设和别人告诉你的结论。