**： dbger的技術部落格
呃， 不要誤會，這不是我給出的建議，我暫時還算不上「優秀」的軟體技術人員。
是這樣，這幾天，從美國那邊過來幾個比較有經驗的同事，因為相對來講，中國這邊的團隊比較年輕，因此安排了乙個「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了？一步一步踏踏實實往前走，才是真正的往前走，依靠在那些浮雲般的假設，你始終都在搖晃。而且，正是這一次次的確認，才構成了你真正的經驗，不然，若干年後，你有的只有自己的假設和別人告訴你的結論。
其實做不到這兩點的，關鍵還是懶：懶得去研究學習，懶得去確認。所以，要成為優秀的技術人員，歸根結底還是勤奮啊！
呃， 不要誤會，這不是我給出的建議，我暫時還算不上「優秀」的軟體技術人員。
是這樣，這幾天，從美國那邊過來幾個比較有經驗的同事，因為相對來講，中國這邊的團隊比較年輕，因此安排了乙個「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了？一步一步踏踏實實往前走，才是真正的往前走，依靠在那些浮雲般的假設，你始終都在搖晃。而且，正是這一次次的確認，才構成了你真正的經驗，不然，若干年後，你有的只有自己的假設和別人告訴你的結論。
其實做不到這兩點的，關鍵還是懶：懶得去研究學習，懶得去確認。所以，要成為優秀的技術人員，歸根結底還是勤奮啊！
想成為乙個優秀的技術人員
找工作的這幾天，收穫頗多。思考得最多的問題可能就是對未來的乙個規劃。無意中看到下面幾條經驗，發現和自己想的也差不多，就分享出來。我要求自己做到這些，同時也希望對您也有所幫助。1 保持學習 乙個非常重要的觀點是 如果你停留在乙個地方不前，並不代表你能一直呆在那裡，而是代表你正在落後 不進則退 往前進並...
成為優秀技術人員必須做到的幾件事情
1.保持學習 乙個非常重要的觀點是 如果你停留在乙個地方不前，並不代表你能一直呆在那裡，而是代表你正在落後 不進則退 往前進並不意味著你是就能進步 這至少你不會淪落到最後 付出就會有收穫 程式設計師為了保持向前發展，就需要不斷學習 我們需要的不是慢慢的往前走，而是我們要奔跑起來！下面列出這方面的幾個...
給工作幾年的技術人員的建議
每個技術開發人員基本都經歷過這樣的經歷，初期對開發技術的熱衷，不斷鑽研，買書，做專案 向前輩學習，基本頭3年是技術人員成長最快的，工資不斷漲，承擔的工作不斷多，職位從初級到專案經理。但做的具體開發也逐漸少了，更多的人員管理 任務分配 系統和資料庫設計。3 5年後大量的時間都子溝通上，忽然某一天，感覺...