为什么打断 15 分钟的代价是 1 个小时

>>> 技術話題—商業文明的嶄新時代 >>>

簡體傳統

过去一个月里我一直在为生产力的问题奋斗。整体而言感觉自己产出不够多。我开始探索原因，找出工作时发生的状况，或者到底是什么阻止了我在项目上有不错的进展。这项研究最终富有成果。

mo·men·tum (mōˈmen(t)əm,məˈmen(t)əm/)动量，动力，势头

一个移动中物体的动力的总量，通过该物体的质量与速度之乘积来测量。

当我坐下来准备编写项目代码，是无法直接进入状态的。如果是从项目起始点开始，或从工作日开始，我不得不先加载很多数据到大脑里。你可以把它想像为大脑内存。

这个部分是用什么语言写的？
该语言的所有语法
目前手头项目的目的是什么？
这是解决这个问题的有效方法吗？
这会导致我以后欠下技术债吗？
这会影响到应用的另一个部分吗？

如果你是领导，你还必须考虑这些：

这是能赚钱/好的商业决策吗？
这是可以复用的吗？
这真的就是最好的用户体验吗？

这些都还只是元细节，都还不涉及手边具体的问题。实际情况是，你遇到的有数学、标准的编程实践、业务逻辑、数据库查询、插件的细微差别、自己的代码细节以及更多的问题。

最佳的动量是以伏笔的形式到来的。即你已经在脑海中勾画出了短期的路线图，并且已经准备好为接下来的两个步骤编码。我最喜欢的方式就是以注释的方式来提早写好步骤。

//链接数据库
//获取客户端信息
//创建数据缓存
//连接到UPS的接口
//使用数据包来创建一个预测
//验证预测
//生成传输标签
//使用 graphicsmagick（此处原文中笔误写成了graphicsmagik）转换原始数据为PDF
//整合多个 PDF 为一个单独的页面
//呈现 PDF 给用户

我喜欢类似这样的清单。它具有挑战性并让你有事可期待。当你知道如何去完成每一项，你的动量会成指数级增加。这些任务被你越发快速、高效地完成，超过你不写清单时的表现。

注：要想直奔主题地考虑可以在哪儿写下上面的清单，你必须至少已经在脑海中完成了任务中基本的部分。

打破动量

有三种情况可以彻底毁掉你的动量。它们可以让你完成任务的能力降低两三倍。

有些事情没有按照预期进展。
有人干扰了你（比如：邮件、Skype、消息、同事、社交网站）
时间到了（回家，睡觉）

有些事情没有按照预期进展

这一点甚是烦人，但是却非常常见。想象一下，你以为知道该如何使用 UPS 的接口，但是它莫名其妙地就是不管用。你之前也曾使用过，非常清楚它应当是如何操作的，然而当你测试的时候，出现一片空白。假如你足够幸运可以得到明确的错误消息反馈，通常还不会失去太多的动量。不然，你就会相当受挫。此时你有如下几个选择：

寻找一些正常运行的代码然后对比差异
在 Google 上搜寻
在 Stackoverflow 上提问
跟一个朋友咨询，去骚扰他们
发布一个问题到 Github，期待有人尽快回复
想出一个新办法

所有这些都只是在彻底毁掉你已有的工作动量。忘掉那个清单，忘掉你要尽快解决掉它，从现在开始你必须全身贯注到这些从未计划会消耗超过两分钟的随机事件上。

对于此，我的解决方案是积累经验。你拥有的经验越多，解决的问题越多，你不能解决问题的机会就少。学会 debug！经验同样能教你如何更有效地Google，以及更快速地查找答案。

打断/中断

各种打断是最大的时间杀手。你的老板、同事、会议，都特别碍事。他们可以让你无法集中精力，并且你离开手头项目的每一分钟其实等同于失去三个小时的动量。

假如你现在正准备编写一个循环来检查所有数据包的大小，内容以及或许还要计算一下体积重量。然后有人问你：“你能快点从数据库抓取一下 XYZ 给我吗？” 我会回答说“好”然后拿到这个数据。但这估计会花掉 4 分钟，因为可能我需要查找一下 SQL 命令或者回忆一下有些数据表的结构。谨记对于任何项目而言（甚至是这个半路杀进来的任务）我都需要加载如上所述的整个清单。此时，第一个项目的大脑内存正在衰减。