声明 

首先声明，本文其实是写给管理程序员的人看的。如果你是程序员，看了以后可能会对你的职业生涯产生负面影响，慎入!

至于其他闲杂人等，可以了解一下码农的工作状态，看个乐子。

 什么是 debug？

程序员的 debug，即除虫、把没有按照预期方式正常运行的代码块修正。

这个过程分为 3 个步骤：

1 找到它

2 想办法解决它

3 确认它已经被解决（并且没有引入其它问题）

很多时候找到 bug 并不难

但很多时候，真的很难！

即使找到了，也通常不容易解决

最糟糕的莫过于，有时候难以验证是否已解决，如上，Debug 并不是那么容易的事。

值得庆幸的是，大多数的 bug 都和上面图示的那样简单。因此，虽然海量的 bug 填满了程序员的工作时间，但软件项目仍然能跑。

至于能不能按时跑完，那就要看程序员的效率了。一个程序员，效率的最大因变量，毫无疑问是个人能力。

如何提高自己的能力？这是程序员职业生涯中永恒的追求。本文避而不谈，只说程序员自己不能改变的一些外部环境因素。

 第一定律：效率并不是时间的均匀分布 

对于有正常生活规律的人来说，这条可以这么描述：

早上 debug，解决一个大于一个

下午 debug，解决一个等于一个

晚上 debug，解决一个小于一个（注：可以小于零）

毫无疑问，debug 是一项智力活动。头脑清醒的时候，效率最高；头脑不清醒的时候…… 嘿嘿…… 我们喜欢称之为埋雷。会不会在下一次以另一种形式，炸到自己或后面的人，这就管不了了，至少当前的这坑填了。

很多 bug，不好好解决，就是这样

当今码农界，弹性工作制（免费加班）已经蔚然成风，996 已成做项目的常态。

但是，朝九晚九，甚至到凌晨，真的能解决？请看上图。

晚上搞到精疲力尽，第二天的状态真的正常？请看上图。

周末仅休息一天，真的能不影响下周的状态？请看上图。

996，强行把早上变成了 “晚上”，把晚上变成了 “下午”。短期来看也许效果不错，但是长期下来，如果人员不流动，或者项目与项目之间有足够的间隙，那么必然整个团队都效率低下。并不是说解决的 bug 少了、慢了，而是让 bug 总量增多了。

八小时工作制不仅仅是曾经的人文追求，也具备生物学上的合理。人，毕竟是一种周期性的生物。

 第二定律：效率和程序员的心情正相关 

一直以来，在文学和影视作品中，都宣称着：

诗人的心情，会影响诗歌的意境（语文试卷上不知写过多少遍）

乐手的心情，会影响音乐的内涵（“高山流水” 的典故）

厨师的心情，会影响食物的味道（还记得那碗 “黯然销魂饭”？）
……

星爷英姿时瞻仰

一首诗，同一个开头，可以有不同的结尾；同一个意思，可以用不同方式表达——这是语言赋予的高自由度所致。而诗歌无论是叙事的、咏志的、还是抒情的，都是智力创造的结果。从脑中创造的东西，很难不受当时脑中充斥的 “心情” 的影响。

对 debug 来说也是一样。

编程语言的自由度虽然比自然语言低多了，但是还是非常高。同一个小功能，让不同的人来从零开始实现，一定会有不同的代码。也许实现同一功能的软件，没有什么好坏之分，但编译之前的代码，一定有高下之别。

找 bug 时，看到整洁的代码，和看到乱七八糟的代码，效率是完全不同的；解 bug 时，是写整洁的代码，还是写乱七八糟的代码，心情真的很重要。

这就是为什么很多新兴互联网公司要效仿 Google 那样的顶级企业：水果随便吃、饮料随便和、甜点随便拿——开心就好。这也是为什么最近在炒作一个职业，叫程序员鼓励师……

当然了，前面说的是程序员认真负责 debug 的情况，不包括携程那小哥儿。

在内部搞技术破坏，真的很简单

携程对那个程序员干了什么?

 第三定律：效率和分配时间的自由度正相关

debug 是程序员把既有代码加载到大脑中模拟执行并且找出其中错漏，的一个过程。

如果有多个 bug，那么解决它们的过程，类似于操作系统的进程调度。程序员需要根据 bug 的优先级、难易度、相关性、重要性等，自行分配处理问题的顺序以及时间，以达到最高的总体解决效率。

而这时候，就怕有个人站出来，说那个 bug 必须先解决；更怕有一群人依次站出来，各自指出一个 bug 要求先解决。

每当从一个 bug 切换到另一个时，代码会在大脑中重新加载。遗憾的是，人的大脑在这件事上，比电脑差太多，会异常耗时。因此，bug 顺序的外在调整，必然带来效率的损失；而长期如此，待解 bug 的队列，只会越来越长。

当程序员在大脑中重新加载一段程序，你知道他要死多少脑细胞吗？

debug 并不是一件越给压力、越催促就越能越快速完成的工作。需要被鞭子撵着干活的，是驴、是牛，不是脑力劳动者。

最高效的办法，就是让程序员自己分配自己的时间，只注重结果。

第零定律

短期高效，往往是长期低效；长期高效，往往是短期低效——以上三条 “定律”，都不过是这一条的具现。人的脑力劳动，就是这么样一种活动，不可能长短兼得。

既希望得到短期高效，又希望收获长期高效，强行违背规律的结果，就是徒劳无功。

今天给你 10 万，或者一年内，分批给你 200 万，怎么选？
一年内给你 200 万，和十年内给你 5000 万，怎么选？
十年内给你 5000 万，和百年内给你 20 亿，怎么选？

人不可能在职场工作百年，而时间也一定会带来货币贬值。但是，最值钱的资产，不会是当前的存款，而是未来稳定的现金流。

只要不是临时的开发 Team，那么长期而稳定的高效，才是真正的高效。

不仅仅是 debug，coding 的工作也有类似规律。debug 是在既有代码的基础上，依次解决一些被打包为 bug 的问题。而 coding 则是，把一件较大的开发任务，拆分为一个个小的 task，然后逐一去完成。

也不仅仅是写代码，所有脑力劳动，都有类似规律。

我到底在表达什么

如果你是管理程序员的人，读完了并且不认同，我建议多想想。

这不是什么新鲜的论调，三十年前的《人月神话》《人件》，都提到过类似的思想。直到今天，很多管理者都承认这俩的地位，但仍然对压榨员工的生命力奉行不悖——因为这样有最好看的短期成果可以呈现给上级。

而今，整个中国互联网都构建在对程序员的压榨上，好像没有什么不合理。似乎加班是王道，主动加班才是上进。

但是，任何强行达到短期高效的手段，最终都将损失更多的长期利益。要么欲速则不达，要么降低软件的质量，要么留不住优秀的员工。

加班、高压、催逼，这些手段，可以做好一个产品，不能做好一个系列；可以做一个品牌，不能做好一个品牌。

如果不能尊重自己手下的脑力劳动者，那么你作为管理者，一生成就也就那样了。如果你是程序员，呃…… 我建议你当没看见，继续 “上进” 去吧。

屁股决定脑袋，屁股应该决定脑袋。在其位谋其政，不在其位不谋其政。没事像我一样看技术以外的书，想技术以外的事，结果就是对老板的诸多做法不以为然，反驳起来还头头是道。最终……

人就应该知足。脑力劳动者往往有智商上的优越感，这已经是难以根治的劣根性了。如果再加上情商上的过度自信，那真是可以目中无人了。

请虚怀若谷，假装不知道吧。

数领先机 智赢未来

DTCC2018

中国数据库技术大会（简称 DTCC）是国内数据库及大数据领域规模最大、最受欢迎的技术交流盛会，每年一届。自 2010 年以来，迄今已成功举办了八届，累计参与人次达到 20000+。DTCC 每年都将邀请百余位行业专家，就热点技术话题进行分享，为数据库人群、大数据从业人员、广大互联网人士及行业相关人士提供最具价值的交流平台。

2018 年 5 月 10-12 日，第九届中国数据库技术大会（DTCC2018）将如约而至。本届大会以 “数领先机 • 智赢未来” 为主题，设定 2 大主会场及 20 个技术专场，邀请来自国内外互联网、金融、教育等行业百余位技术专家，共同探讨 Oracle、MySQL、NoSQL、大数据、机器学习、区块链、数据可视化等领域的前瞻性热点话题与技术。

点击左下阅读原文，立即购票~