防火和救火哪个更重要呢？几乎所有的人都会给出一致的答案：当然是防火更重要啦。确实如此，我也认为防火比救火更重要。然而，看看现实中的情况吧，我们经常看到某某消防员不顾生命危险消灭了一场大火，获得各界的表扬和赞誉，被誉为英雄， 如果不幸牺牲， 还会被追封为烈士。却很少见到社会各界表扬那些防火工作做得很好的人。这就有点意思了：救火队员受到表扬，防火工作做得好的人，反而当成默默无闻的不作为之人， 没有奖励， 只能喝西北风。
这就产生了这样一个事实，从口号和宣传上来讲，各级都强调防火比救火更重要，但从实际评价来看，最终总是表扬那些救火的人。
在软件开发中，也有类似的现象。项目的领导总在强调代码质量，高质量就意味着bug相对较少。但问题是，代码质量高了， bug少了，领导看不到你有什么功劳啊，最后绩效考评的时候，会被认为工作量不饱和。 相反，代码质量差的人，到处制造bug,然后火急火燎地解决bug,在邮件里面分析bug,搞得头头是道，然后抄送一大堆领导，刷刷存在感，意思是告诉领导，我很忙啊，我没闲着，我分析问题鞭辟入里，我解决问题雷厉风行。领导嘛，看到这个邮件上的分析和汇报，内心自然是对该程序员多了一些好的印象，觉得很靠谱很干练，年终绩效考评的时候，自然有所倾向。
我来将上面的现象具体化，以前我举个一个例子，现在引用如下：
第一种程序猿(救火程序员)，花了一天时间，就快速地实现了某一软件功能，但是写的代码风格很差，别人难以读懂，该加代码注释的地方不加，该加异常判断的地方不加，不考虑什么代码框架。结果呢，当场景复杂后，代码bug到处跑出来，于是又忙乎地搞了两天的bug定位和修改。这三天，领导看到了他的快速，看到了他的忙碌，看到了他加班那么晚回去，心想，真是好员工啊，我要给他打个好的绩效。
第二种程序猿(防火程序员)，花了两天时间实现了同一功能，代码风格好，该加注释的地方也加了，别人一读就懂，而且考虑了异常情况，代码有较好的可扩展性。结果呢，即使在复杂的场景中，代码也体现了很强的稳健性，基本上没有什么bug,第三天呢，就相对比较清闲。这三天，领导看到的是他前两天的慢速，心想，别人搞一天就搞出来了，你非要搞两天，用你成本好高啊，关键是，第三天别人都在火急火燎搞bug,你却这么清闲，心想，你工作态度不端正，拿钱不做事，是该给你派更多的活了，另外，你也别想要什么绩效。
最后的结果，不言而喻。 救火程序员比防火程序员混得更好。
不得不说， 防火程序员才是功劳最大的人， 但绝大多数现实的结果不得不令我们反思， 考评机制哪里出了问题？ 如何更大程度上保护防火程序员？ 我相信， 防火程序员吃香的团队， 远胜于救火程序员吃香的团队。
不过呢，我们的老祖宗早就悟出了“养寇自保”的道理， 不留一些敌人， 怎能自保？ 所谓飞鸟尽，良弓藏；狡兔死，走狗烹。程序员呢？ 自然会吊儿郎当地认为： 不制造bug, 何以立足于江湖？