点击上方“程序员大咖”，选择“置顶公众号”
关键时刻，第一时间送达！
有感于知乎上的一篇关于程序员的讨论。让我突然之间心有戚戚然的感觉。最近一段时间有点江郎才尽的感觉，写不了大的主题，就写点小东西吧。
我们从知乎上面引用的这段小故事开始：
魏文王问扁鹊家里三兄弟谁的医术最好。扁鹊回答说大哥最好，二哥次之，他自己最差。魏文王疑惑了，又问道，为什么扁鹊最有名呢?扁鹊回答说因为大哥治病的时候人没病就防止了，所以毫无名气。二哥呢，病刚起来的时候，就给治好了，大家以为只能治小病。而自己呢，能耐不够，非要到了病的很厉害了才能看出来，治起来的动静就大了。好在还不至于庸医能治好，结果大家看到每次治的都是顽疾，反而出名了。
这发生在几千年前的对话是不是靠谱我们不知道，但是拿这话来套程序员的生态圈，真就是一套一个准。
微软某个大牛软件下面两个不同的组里各有一个大牛程序员，为了不失一般性，我们叫张三和李四吧。张三的特点颇有点大哥的风范，偶尔也充当一下二哥。写的程序严谨，测试也很严谨，几乎不犯错。组里其他同事有错的，也在出大事之前默默的修掉了。
李四的风格和扁鹊像，手脚麻利干活快，但是坑也很多。好在李四人聪明又手脚麻利，每次总是能够在自己或者组里其他人搞出惊天动地的大事来的时候，把坑迅速填好，救产品于危难。
名气来说，李四是整个产品部门从VP往下数出了名的可靠的火枪手，救火队员。领导信任不可或缺的左膀右臂。张三就默默无闻了。只有小组里面的人知道自己是高手。
说起结局来，李四很快就到了principal，张三么，一直默默无闻，很多年以后终于熬资历到了senior，然后在一次裁员中被裁掉了。
事情到这里就有点意思了。几千年前的故事，几千年后还在上演。看官可能觉得这个是特例。其实也不然。这样的故事一直在上演。
说说另外一个顺利上市扩张的公司的故事。我们知道但凡是初创公司里的员工，都是能够迅速的开发出差不多能用的东西的工程师的天下。但是这个东西有个度，差不多能用的东西短平快带来的副作用其实很大。弄不好就得在未来某个时候全部重写。
这个公司的领导层就是这样一群码农自然而然的升上来的，崇尚的就是这种做事风格。但是因为公司大了，产品不能够再到处是bug了，可是公司的test coverage又是一塌糊涂。哪里都是坑。所以每次新版本的发行，都不停的延期延期又延期。
公司里我认识的有一个俄罗斯来的人，做事情严谨，写程序的test coverage很好，因为以前合作的关系，知道这个人的工作style，而且知道这个人是我见过的最为优秀的程序员之一。有次我偶遇聊起天来，这位一个劲的和我诉苦，苦不该去这个公司。因为公司里面所有的人崇尚的是救火队员，从未有人觉得好好写code，少出bug是重要的。
后来我又认识了一个罗马尼亚来的工程师，也是同一个公司。这位罗马尼亚老兄的程序我就不评价了，实在有点不堪入目。然而我看看linkedin，在此公司混的是风生水起。我再次和俄罗斯人见到的时候，俄罗斯人和我说，这个罗马尼亚人啊，就是个彻头彻尾的hacker。每次做事情，把当前的bug能修掉再说，code一塌糊涂，最后别人都得替他擦屎。但是领导们都很喜欢他啊，能迅速的修好东西让产品出去。
这事情说道这里，其实可以概括下来两句话：曲突徒新亡恩泽，焦头烂额为上客。
一个程序员为了不出问题而做的努力，往往没有那些出了问题以后再打鸡血一样去努力解决的人获得的回报多。你说按照这个标准去判断，到底是哪里出错了呢?
从这一点来说，我们首先得要看看一个领导是怎么样去评价一个好或者不好的程序员的。在我的经历里面，并不是没有遇到过在意系统结构，对那些能够写出不错的程序，能够防范未然的程序员非常重视的领导。然而更多的领导其实最在乎的依然是如何能够迅速的把东西写完，迅速的发布出去。
基于后者的情况越来越普遍，尤其是在比如著名的亚马逊的很多产品组，领导有的是MBA或者产品经理出身的，其评价体系里面，并不会给扁鹊大哥那样的程序员太多发挥的空间。
我作为程序员的时候，是非常希望自己可以成为扁鹊大哥这样的牛逼的大神的。我环顾四周的时候，看到拯救公司的英雄们，各个都如同扁鹊，或者扁鹊++。这个问题我很困扰了，读到知乎上的文章，颇心有戚戚然。那么码农们，你们怎么选?经理们，你们怎么看?
来自：程序师
程序员大咖整理发布，转载请联系作者获得授权
