在大型公司中不能腐蝕本身的學習能力和時間能力。
最近我爲一個內核程序員的職位面試了十幾個候選人。這些候選人都來自一些不錯的大公司,這些公司在芯片或嵌入式操做系統領域十分有名。這些候選人大多聲稱本身在內核方面有着十年的在職工做經驗。他們的簡歷看起來很是耀眼——各類相關的項目、術語和獎項……
但他們幾乎無人可以回答一個很是基礎的問題:
當咱們調用標準的malloc函數時,內核中會發生什麼?
先別吃驚。當我要求其中一位候選人基於glib的哈希函數寫一個簡單的LRU緩存框架時,他先是表示歷來沒用過glib——這正是我所指望的——因而我幫他打開了glib哈希API的頁面,並向他詳細講解了這些API;而後大約一個小時之後,他只寫出幾行凌亂的代碼。
我不知道其它國家是否也有相似的狀況,但在中國,或者更精確一些,在北京,這就是現狀。
那些在不錯的大公司裏工做了多年的「資深」程序員們沒法在一些簡單的、基本的問題上證實本身。
這究竟是怎麼回事
當我在這個問題上思索得越多,我就更加相信,這不只有他們自身的緣由,同時也歸咎於他們所供職的這些公司。這些公司一般提供了一個穩定的代碼堆,每每幾年都不會有大更新。這些代碼的專有技術把人們的技能框進一個定式,以至於他們只須要遵循現有的路徑,而不須要發揮創意。若是你碰巧爲這類代碼工做,並且與世隔絕了很長一段時間,那麼有一天你會發現你本身已經陷入一個可悲的位置——他們在團隊或公司內稱呼你爲「專家」,但不幸的是,你沒法在市場上找到一份同等待遇的工做。
這就叫做「
專家陷阱」。日復一日,程序員們都渴望在團隊或公司內成爲一名專家;可是,當那一天真正到來時,咱們卻早已做繭自縛。咱們在既有代碼中鑽得越深,咱們本身就陷得越深。既有代碼是如此穩定(如此寵大、如此好用),讓咱們漸漸地失去了從無到有獨立編寫完整項目的能力。更糟糕的是,若是咱們的主要工做就是維護這些既有代碼、不多開發新功能,那麼過不了多久,不管研讀了多少代碼,咱們都會發現本身不會寫代碼了——哪怕是一個像畢業大做業那樣簡單的任務。這就是程序員的困境:
咱們以編碼爲生,但那些養活咱們的大公司卻在無形中磨滅了咱們的生存技能。
如何打破這種困境?
對於我的:
首先,打造你本身的私人項目。你須要不斷地打磨本身的技藝。若是工做自己並不能幫助你作到這一點,就撿起那些你感興趣的問題,而後用你的私人時間去攻克它。經過這個方法,你應該會學到新東西。若是把你的私人項目發佈出去,好比在GitHub上,你說不定會認識一些人,幫助你大踏步地向前邁進。
不要在一個團隊中停留超過兩年。強迫你本身四處轉轉,哪怕在是同一家公司內,你會面對新的挑戰和新的技術。試着每隔18個月就出去面試工做。你並不須要真的換工做,可是這能讓你看到真實的市給予員工壓力和挑戰。實行輪崗制度,讓「專家」們有機會拓展他們的技能。啓動新項目,用戰役來磨鍊你的勇士。
對於團隊和公司:
給予員工壓力和挑戰。實行輪崗制度,讓「專家」們有機會拓展他們的技能。啓動新項目,用戰役來磨鍊你的勇士。
週期性地舉辦黑客馬拉松活動。這有助於營造一種崇尚創新和創做的企業文化,人們會受到同伴的激勵——「擦,這個混蛋竟然能夠在24小時內寫出這麼漂亮的框架,我也得加把勁兒了!」