成為優秀技術人員的兩點建議

2022-08-14 03:33:12 字數 2666 閱讀 3767

**: 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年後大量的時間都子溝通上,忽然某一天,感覺...