是這樣，這幾天，從美國那邊過來幾個比較有經驗的同事，因為相對來講，中國這邊的團隊比較年輕，因此安排了一個“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了？一步一步踏踏實實往前走，才是真正的往前走，依靠在那些浮云般的假設，你始終都在搖晃。而且，正是這一次次的確認，才構成了你真正的經驗，不然，若干年后，你有的只有自己的假設和別人告訴你的結論。