近日筆者采訪了幾十位求職內(nèi)核程序員這個崗位的候選人。這些候選人均來自大的優(yōu)秀公司——公司多以芯片或嵌入式OS /系統(tǒng)而聞名。他們中的許多人都聲稱自己擁有至少10年的內(nèi)核在職經(jīng)驗。他們的簡歷非常耀眼——各種相關(guān)的項目，流行語和獎項……

但大多數(shù)人卻無法回答一個很基本的問題：當我們調(diào)用標準malloc函數(shù)時，內(nèi)核會發(fā)生什么？

[[159642]]

不要驚訝。當我要求其中一位候選人基于glib哈希函數(shù)編寫一個簡單的LRU緩存框架時，他一開始表示他從未使用過glib——這也在我意料之中——我給他展示了glib的哈希API頁面，并詳細解釋了API，然后在將近一個小時之后，他只寫出了幾行亂七八糟的程式碼。

我不知道其他國家的情況是否類似，但在中國，或者更具體地說，是在北京，這是現(xiàn)實。那些曾為大型著名外企工作多年的“高級”程序員往往在簡單、基本的問題上束手無策。

為什么會出現(xiàn)這種情況？

我越是思考這個問題，就越是覺得問題的原因不僅僅在于他們本身，也在于他們工作的公司。這些公司通常會提供穩(wěn)定的代碼堆棧，而且多年以來一直沒有產(chǎn) 生顯著的變化。圍繞代碼的技術(shù)封閉了程序員的技能，使得他們只需要遵循現(xiàn)有路徑，而不必積極創(chuàng)新。如果你在這種代碼上工作了很長一段時間，同時沒有很好地 與時俱進，那么總有一天你會發(fā)現(xiàn)自己進退兩難——在團隊或公司內(nèi)部，他們叫你“專家”，但卻無法在市場上找到同樣棒的工作。

這就是所謂的“專家陷阱”。日復一日，程序員夢想著成為團隊/公司內(nèi)部的專家——然而，當這一天真正來臨的時候，卻是我們困住自己的時候。我們對現(xiàn) 有代碼挖掘得越深，我們陷入的泥潭就越深。我們漸漸失去了從頭開始編寫完整項目的能力，因為現(xiàn)有的代碼是如此之穩(wěn)定（如此之大，如此之有利可圖）。更糟糕 的是，如果我們的主要工作就是維護現(xiàn)有代碼，那么一段時間之后，無論我們閱讀和學習了多少代碼，都會發(fā)現(xiàn)，自己不會寫代碼了——即使問題簡單到如研究生院 的作業(yè)。這就是程序員的困境：我們靠編碼為生，但培養(yǎng)了我們的大公司往往會破壞我們謀生的能力。

如何擺脫這種困境？

對于個人——

首先，要做自己的個人項目。你需要不斷地“提升自己”。如果工作本身不能幫助你提升自我，那么找一些你想在個人時間解決的問題。這樣做有助于你學到新的東西。如果你發(fā)布個人項目，比如說在github上，那么你就有機會認識那些能在你換工作時拉你一把的人。

不要停留在同一個團隊超過兩年。強迫自己換崗位，即使是在同一組織，同一公司中，這樣你就可以面對新的挑戰(zhàn)和新的技術(shù)。每隔18個月去參加工作面試。這不是為了跳槽，而是為了讓自己知道現(xiàn)在市場需求什么，以及你該如何適應。

對于團隊/公司——

給予員工壓力和挑戰(zhàn)。輪換崗位，讓所謂的“專家”有機會擴充他們的技能。開啟新項目，用實戰(zhàn)來磨練大家。

定期舉辦黑客馬拉松。這將有助于建立一種擁抱創(chuàng)新和創(chuàng)造的文化。大家會因彼此而受到激勵—— “哎呀，那個家伙能用24小時寫出這樣一個美麗的框架，我得加油了”。

譯文鏈接：http://www.codeceo.com/article/programmer-dilemma.html
英文原文：Programmer’s dilemma