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