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