起航学习网

1

我们引用的这段小故事开始：

魏文王问扁鹊家里三兄弟谁的医术最好。扁鹊回答说大哥最好，二哥次之，他自己最差。魏文王疑惑了，又问道，为何扁鹊最有名呢?

扁鹊回答说因为大哥治病的时候人没病就防止了，所以毫无名气。二哥呢，病刚起来的时候，就给治好了，大家以为只能治小病。而自己呢，能耐不够，非要到了病的很厉害了才能看出来，治起来的动静就大了。好在还不至于庸医能治好，结果大家看到每次治的都是顽疾，反而出名了。

这发生在几千年前的对话是不是靠谱我们不知道，但是拿这话来套程序猿的生态圈，真就是一套一个准。

2

微软某个大牛软件下面两个不同的组里各有一个大牛程序猿，为了不失一般性，我们叫张三和李四吧。

张三的特点颇有点大哥的风范，偶尔也充当一下二哥。写的程序严谨，测试也很严谨，几乎不犯错。组里其他同事有错的，也在出大事之前默默的修掉了。

李四的风格和扁鹊像，手脚麻利干活快，但是坑也很多。好在李四人聪明又手脚麻利，每次总是能够在自己或者组里其他人搞出惊天动地的大事来的时候，把坑迅速填好，救产品于危难。

名气来说，李四是整个产品部门从VP往下数出了名的可靠的火枪手，救火队员。领导信任不可或缺的左膀右臂。张三就默默无闻了。只有小组里面的人知道自己是高手。

说起结局来，李四很快就到了 principal，张三么，一直默默无闻，很多年以后终于熬资历到了 senior，然后在一次裁员中被裁掉了。

3

事情到这里就有点意思了。几千年前的故事，几千年后还在上演。看官可能觉得这个是特例。其实也不然。这样的故事一直在上演。

说说另外一个顺利上市扩张的公司的故事。我们知道但凡是初创公司里的员工，都是能够迅速的开发出差不多能用的东西的工程师的天下。

但是这个东西有个度，差不多能用的东西短平快带来的副作用其实很大。弄不好就得在未来某个时候全部重写。

这个公司的领导层就是这样一群码农自然而然的升上来的，崇尚的就是这种做事风格。

但是因为公司大了，产品不能够再到处是 bug 了，可是公司的 test coverage 又是一塌糊涂。哪里都是坑。所以每次新版本的发行，都不停的延期延期又延期。

公司里有一个俄罗斯来的人，做事情严谨，写程序的 test coverage 很好，因为以前合作的关系，知道这个人的工作 style，而且知道这个人是我见过的最为优秀的程序猿之一。

有次我偶遇聊起天来，这位一个劲的和我诉苦，苦不该去这个公司。因为公司里面所有的人崇尚的是救火队员，从未有人觉得好好写 code，少出 bug 是重要的。

后来一个罗马尼亚来的工程师，也是同一个公司。这位罗马尼亚老兄的程序我就不评价了，实在有点不堪入目。然而我看看 linkedin，在此公司混的是风生水起。

我再次和俄罗斯人见到的时候，俄罗斯人和我说，这个罗马尼亚人啊，就是个彻头彻尾的 hacker。

每次做事情，把当前的 bug 能修掉再说，code 一塌糊涂，最后别人都得替他擦屎。但是领导们都很喜欢他啊，能迅速的修好东西让产品出去。

4

这事情说道这里，其实可以概括下来两句话：曲突徒薪亡恩泽，焦头烂额为上客。

一个程序猿为了不出问题而做的努力，往往没有那些出了问题以后再打鸡血一样去努力解决的人获得的回报多。你说按照这个标准去判断，到底是哪里出错了呢?

从这一点来说，我们首先得要看看一个领导是怎么样去评价一个好或者不好的程序猿的。

在我的经历里面，并不是没有遇到过在意系统结构，对那些能够写出不错的程序，能够防范未然的程序猿非常重视的领导。然而更多的领导其实最在乎的依然是如何能够迅速的把东西写完，迅速的发布出去。

基于后者的情况越来越普遍，尤其是在比如著名的亚马逊的很多产品组，领导有的是 MBA 或者产品经理出身的，其评价体系里面，并不会给扁鹊大哥那样的程序猿太多发挥的空间。

我作为程序猿的时候，是非常希望自己可以成为扁鹊大哥这样的牛逼的大神的。我环顾四周的时候，看到拯救公司的英雄们，各个都如同扁鹊，或者扁鹊++。

那么码农们，你们怎么选?经理们，你们怎么看?

感谢大家阅读由Java培训学校分享的“好的程序猿和不好的程序猿”希望对大家有所班助，更多精彩内容请关注Java培训官网 

免责声明：本文素材由小T转载自网络，旨在分享提供阅读，版权归原作者所有，如有侵权请联系我们进行删除

文章出自：http://qh.itpxw.cn/peixun/software/202191613.html

文章标题：好的程序猿和不好的程序猿

免责声明：本站文章均由入驻起航学习网的会员所发或者网络转载，所述观点仅代表作者本人，不代表起航学习网立场。如有侵权或者其他问题，请联系举报，必删。侵权投诉