好與壞的程式設計師:如何客觀評價程式設計師的水平?

1

有感於知乎上的一篇關於程式設計師的討論。讓我突然之間心有戚戚然的感覺。最近一段時間有點江郎才盡的感覺，寫不了大的主題，就寫點小東西吧。

我們從知乎上面引用的這段小故事開始：

魏文王問扁鵲家裡三兄弟誰的醫術最好。扁鵲回答說大哥最好，二哥次之，他自己最差。魏文王疑惑了，又問道，為什麼扁鵲最有名呢?扁鵲回答說因為大哥治病的時候人沒病就防止了，所以毫無名氣。二哥呢，病剛起來的時候，就給治好了，大家以為只能治小病。而自己呢，能耐不夠，非要到了病的很厲害了才能看出來，治起來的動靜就大了。好在還不至於庸醫能治好，結果大家看到每次治的都是頑疾，反而出名了。

這發生在幾千年前的對話是不是靠譜我們不知道，但是拿這話來套程式設計師的生態圈，真就是一套一個準。

2

微軟某個大牛軟體下面兩個不同的組裡各有一個大牛程式設計師，為了不失一般性，我們叫張三和李四吧。張三的特點頗有點大哥的風範，偶爾也充當一下二哥。寫的程序嚴謹，測試也很嚴謹，幾乎不犯錯。組裡其他同事有錯的，也在出大事之前默默的修掉了。

李四的風格和扁鵲像，手腳麻利幹活快，但是坑也很多。好在李四人聰明又手腳麻利，每次總是能夠在自己或者組裡其他人搞出驚天動地的大事來的時候，把坑迅速填好，救產品於危難。

名氣來說，李四是整個產品部門從VP往下數出了名的可靠的火槍手，救火隊員。領導信任不可或缺的左膀右臂。張三就默默無聞了。只有小組裡面的人知道自己是高手。

說起結局來，李四很快就到了principal，張三麼，一直默默無聞，很多年以後終於熬資歷到了senior，然後在一次裁員中被裁掉了。

3

事情到這裡就有點意思了。幾千年前的故事，幾千年後還在上演。看官可能覺得這個是特例。其實也不然。這樣的故事一直在上演。

說說另外一個順利上市擴張的公司的故事。我們知道但凡是初創公司裡的員工，都是能夠迅速的開發出差不多能用的東西的工程師的天下。但是這個東西有個度，差不多能用的東西短平快帶來的副作用其實很大。弄不好就得在未來某個時候全部重寫。

這個公司的領導層就是這樣一群碼農自然而然的升上來的，崇尚的就是這種做事風格。但是因為公司大了，產品不能夠再到處是bug了，可是公司的test coverage又是一塌糊塗。哪裡都是坑。所以每次新版本的發行，都不停的延期延期又延期。

公司裡我認識的有一個俄羅斯來的人，做事情嚴謹，寫程序的test coverage很好，因為以前合作的關係，知道這個人的工作style，而且知道這個人是我見過的最為優秀的程式設計師之一。有次我偶遇聊起天來，這位一個勁的和我訴苦，苦不該去這個公司。因為公司裡面所有的人崇尚的是救火隊員，從未有人覺得好好寫code，少出bug是重要的。

後來我又認識了一個羅馬尼亞來的工程師，也是同一個公司。這位羅馬尼亞老兄的程序我就不評價了，實在有點不堪入目。然而我看看linkedin，在此公司混的是風生水起。我再次和俄羅斯人見到的時候，俄羅斯人和我說，這個羅馬尼亞人啊，就是個徹頭徹尾的hacker。每次做事情，把當前的bug能修掉再說，code一塌糊塗，最後別人都得替他擦屎。但是領導們都很喜歡他啊，能迅速的修好東西讓產品出去。

4

這事情說到這裡，其實可以概括下來兩句話：曲突徙薪亡恩澤，焦頭爛額為上客。

一個程式設計師為了不出問題而做的努力，往往沒有那些出了問題以後再打雞血一樣去努力解決的人獲得的回報多。你說按照這個標準去判斷，到底是哪裡出錯了呢?

從這一點來說，我們首先得要看看一個領導是怎麼樣去評價一個好或者不好的程式設計師的。在我的經歷裡面，並不是沒有遇到過在意系統結構，對那些能夠寫出不錯的程序，能夠防範未然的程式設計師非常重視的領導。然而更多的領導其實最在乎的依然是如何能夠迅速的把東西寫完，迅速的發布出去。

基於後者的情況越來越普遍，尤其是在比如著名的亞馬遜的很多產品組，領導有的是MBA或者產品經理出身的，其評價體系裡面，並不會給扁鵲大哥那樣的程式設計師太多發揮的空間。

我作為程式設計師的時候，是非常希望自己可以成為扁鵲大哥這樣的牛逼的大神的。我環顧四周的時候，看到拯救公司的英雄們，各個都如同扁鵲，或者扁鵲++。這個問題我很困擾了，讀到知乎上的文章，頗心有戚戚然。那麼碼農們，你們怎麼選?經理們，你們怎麼看?

來自：51CTO 作者：徐飛