有感于知乎上的一篇關于程序員的討論，讓我突然之間心有戚戚然，最近一段時間有點江郎才盡的感覺，寫不了大的主題，就寫點小東西吧。
我們從知乎上面引用的這段小故事開始：
魏文王問扁鵲家里三兄弟誰的醫術最好。扁鵲回答說大哥最好，二哥次之，他自己最差。魏文王疑惑了，又問道，為什么扁鵲最有名呢?扁鵲回答說因為大哥治病的時候人沒病就防止了，所以毫無名氣。二哥呢，病剛起來的時候，就給治好了，大家以為只能治小病。而自己呢，能耐不夠，非要到了病的很厲害了才能看出來，治起來的動靜就大了。好在還不至于庸醫能治好，結果大家看到每次治的都是頑疾，反而出名了。
這發生在幾千年前的對話是不是靠譜我們不知道，但是拿這話來套程序員的生態圈，真就是一套一個準。
故事一
微軟某個大牛軟件下面兩個不同的組里各有一個大牛程序員，為了不失一般性，我們叫張三和李四吧。張三的特點頗有點大哥的風范，偶爾也充當一下二哥。寫的程序嚴謹，測試也很嚴謹，幾乎不犯錯。組里其他同事有錯的，也在出大事之前默默的修掉了。
李四的風格和扁鵲像，手腳麻利干活快，但是坑也很多，好在李四人聰明又手腳麻利，每次總是能夠在自己或者組里其他人搞出驚天動地的大事來的時候，把坑迅速填好，救產品于危難。
名氣來說，李四是整個產品部門從VP往下數出了名的可靠的火槍手，救火隊員。領導信任不可或缺的左膀右臂，張三就默默無聞了，只有小組里面的人知道自己是高手。
說起結局來，李四很快就到了principal，張三嘛，一直默默無聞，很多年以后終于熬資歷到了senior，然后在一次裁員中被裁掉了。
故事二
事情到這里就有點意思了，幾千年前的故事，幾千年后還在上演，看官可能覺得這個是特例，其實不然，這樣的故事一直在上演。
說說另外一個順利上市擴張的公司的故事。我們知道但凡是初創公司里的員工，都是能夠迅速的開發出差不多能用的東西的工程師的天下，但是這個東西有個度，差不多能用的東西短平快帶來的副作用其實很大，弄不好就得在未來某個時候全部重寫。
這個公司的領導層就是這樣一群碼農自然而然的升上來的，崇尚的就是這種做事風格，但是因為公司大了，產品不能夠再到處是bug了，可是公司的test coverage又是一塌糊涂，哪里都是坑，所以每次新版本的發行，都不停的延期、延期又延期。
公司里我認識的有一個俄羅斯來的人，做事情嚴謹，寫程序的test coverage很好，因為以前合作的關系，知道這個人的工作style，而且知道這個人是我見過的最為優秀的程序員之一。有次我偶遇聊起天來，這位一個勁的和我訴苦，苦不該去這個公司。因為公司里面所有的人崇尚的是救火隊員，從未有人覺得好好寫code，少出bug是重要的。
后來我又認識了一個羅馬尼亞來的工程師，也是同一個公司，這位羅馬尼亞老兄的程序我就不評價了，實在有點不堪入目，然而我看看linkedin，在此公司混的是風生水起。我再次和俄羅斯人見到的時候，俄羅斯人和我說，這個羅馬尼亞人啊，就是個徹頭徹尾的hacker~每次做事都是把當前的bug修掉再說，code一塌糊涂，最后別人都得替他擦屎，但是領導們都很喜歡他啊，能迅速的修好東西讓產品出去。
思考
這事情說到這里，其實可以概括下來兩句話：曲突徙薪亡恩澤，焦頭爛額為上客。
一個程序員為了不出問題而做的努力，往往沒有那些出了問題以后再打雞血一樣去努力解決的人獲得的回報多，你說按照這個標準去判斷，到底是哪里出錯了呢?
從這一點來說，我們首先得要看看一個領導是怎么樣去評價一個好或者不好的程序員的。在我的經歷里面，并不是沒有遇到過在意系統結構，對那些能夠寫出不錯的程序，能夠防范未然的程序員領導是非常重視，然但更多的領導其實最在乎的依然是如何能夠迅速的把東西寫完，迅速的發布出去。
基于后者的情況越來越普遍，尤其是在比如著名的亞馬遜的很多產品組，領導有的是MBA或者產品經理出身的，其評價體系里面，并不會給扁鵲大哥那樣的程序員太多發揮的空間。
我作為程序員的時候，是非常希望自己可以成為扁鵲大哥這樣的牛逼的大神的。我環顧四周的時候，看到拯救公司的英雄們，各個都如同扁鵲，或者扁鵲++。這個問題我很困擾了，讀到知乎上的文章，頗心有戚戚然。那么碼農們，你們怎么選?經理們，你們怎么看?
