我轻轻拍着三个程序员的肩膀并问他们在做什么。“我在重构这些方法”，第一个程序员说。“我在为这些web动作添加一些参数”，第二个程序员说。而最后那个程序员却说：“我正在研究这个用户故事。”
前两个程序员貌似都专注于细节，只有第三个能看到更大的画面，显然后者的聚焦更棒。然而，当我问何时提交什么，情况就发生了变化。前两个十分清楚会涉及到哪些文件并在一小时左右完成。第三个程序员的回答基本上是这样的：“噢！我应该要准备几天时间。我可能要增加几个类，并改变现有的服务机制”。
前两个缺乏全局视角。他们选择由生产方向引领的任务，并可以在几小时内完成。完成这些任务后，他们会选择实现新功能或者重构。所有代码都有明确的用途、范围、可实现的目标。
第三个程序员没有分解问题，同时处理所有部分。他无法采取任何措施，基本上只能投机性的编程，寄希望能够让某些点达到可以提交的程序。最终这个花长时间讨论后才开始写的代码，极有可能与终极解决方案相差甚远。
如果前两个程序员的任务会花费两小时以上，他们会怎么做？意识到自己承担太重后，他们最有可能抛弃他们的变更，定义更小的任务，然后重新开始。因为保持原样的话会找不到重点，从而导致投机性代码提交进仓库。相反，变更被抛弃了，但对其中的洞悉却得到保留。
第三个程序员则可能继续瞎猜，拼命尝试给他的变更打补丁，以拼凑成可以提交的内容。毕竟，你又不能抛弃已经完成变更的代码——那就等同于之前的努力白费了，不是么？悲剧的是，不抛弃这些代码将进一步导致那些目标不明确的诡异代码提交到仓库。
某些时候，即使“聚焦提交”的程序员也可能无法找到自认为可以在两小时内完成的有用内容。然后，他们会进入投机模式，开始调戏代码，一旦有所洞悉，他们就会回到正轨，并抛弃之前的变更。即便这些看似凌乱的黑客会议也是有目的的：为了了解定义出能够形成高效任务的代码。
知道你的下次提交。如果你无法完成，就抛弃这次变更，然后通过你的见解，定义靠谱的任务。如果有需要，就做那些投机性上演，但要注意别掉到投机模式的坑里。不要提交猜测性的工作到你的仓库里。
