（根据真实事件改编，情节有所夸张，请勿对号入座。）
这是一个风和日丽的星期五下午，Ben和Martin本应该在Costa咖啡馆喝一杯下午茶，一起聊聊周末的计划，然而PM的一个微信通知打乱了这一切。原来产品出现了一个bug需要紧急修复，下班之前必须要搞定。两人收到消息疾步走回到岗位，也没了心情去喝刚泡好的咖啡，连忙打开邮箱查看问题报告。
开始
Ben：看来这不是一个很大的问题，就是处理一个来自于远端服务的异常。现在的情况是BFF(backend for frontends)在内部的远端服务有异常，会将异常直接返回到客户端，这样只要一个保单出了问题，前端所有的保单也都没法用了。
Martin：那怎么解决？
Ben：感觉可以在异常的地方加一个异常处理。这个涉及到RxJava和Java8的stream特性，我不是太熟悉，要不我们一起Pair吧
Martin：好。
两人喝了一口炙热的咖啡，摆好键盘鼠标，打开了IntelliJ工程。几分钟后，这个故障重现了。
Martin：可以重现的故障通常比较好解决。我们在这里先弄个try…catch试试。 两人似乎很有信心，然而重启项目后，故障并没有按照预期停下来。
Ben：hmm，这里为什么停不下来呢？
Martin：可能是RxJava的延迟处理，没有正确的捕捉到。这样，你在这里再写一个逻辑，然后在这里设个断点……
焦急
在这个过程中，Martin只是对着屏幕指指点点，时不时看看手机、在微信上聊聊天。Ben对RxJava并不是很熟悉，他想紧紧跟随Martin的思路，然而增加多个逻辑以后，依然都不能解决问题。15分钟已经过去，Ben这时候心生怀疑，是不是哪些地方没弄对？
Ben：我们理一下思路看看？
Martin：恩，来吧，一起看一下代码。
Martin领着Ben一起看了一下代码，并且一直在旁边指点Ben进行单步调试。由于RxJava的延迟特性，使得断点很难设置。而抛出异常的调用栈会出现在某些莫名其妙的地方，这让他们根本不知道把try…catch放在哪里才能奏效。
Ben：可能是要这样，在这里加一个OnError看能不能解决。
看似问题能够解决，其实是又一次的失败。在两人的激烈讨论中，时间过得很快，一晃眼已经是1个小时以后，咖啡早已经凉了，然而两个人完全没有心情，甚至都忘了咖啡的存在。
Ben对Martin的解决方案越来越没有信心，两人开始重新讨论起解决方案。然而方案是越讨论越复杂，看起来想在下班前解决这个问题是不可能了，通宵是必然了。
简化
Zen是组里的Tech Lead，今天在忙另外一个事情。这个周五真是不得安宁，恨不得想到美国去过过昨天。
Zen听到两个人的讨论，虽然并不了解这个问题的细节，但直觉上认为是跑偏了。马上提醒Ben和Martin：
这不是一个很难的问题，我感觉你们想复杂了？是不是走偏了？能给我说一下你们怎么想的么？
被Zen打断的Martin说了一下之前的解决方案，也说试过了其他的方案了，都不行。由于Zen对这个事情也不是很了解，所以只是提了一个醒：
“Keep it simple，别把事情整复杂了。”
两个人的讨论依然在继续，Ben有点无法跟上Martin的思路，艰难地写着代码，但每次都不对。Pair的气氛犹如冬日里冰冷的咖啡一样凝结，不知道孰是孰非。Ben已经有些不高兴，Martin则依然在一旁指指点点但并不动手。
Zen一看表已经3点钟了，又插了一句嘴：
Martin，既然你对这个更熟悉，你来操刀吧。你来写代码吧。
可能由于之前的讨论过于激烈，Martin反驳Zen：
我们在Pair啊，他对RxJava不熟悉，我应该指导他。我看着他写就可以了。
Zen说，
你们的解决方案是什么，给我看看。
解释了一通以后，Zen也没有更多的想法，就让他们继续吧。但Zen建议道：
在这个紧要的关头，我们应该改变一下Pair的方式。现在不是教授知识，而是要高效的解决问题。在这种压力的情境下，你可以直接实现自己的思路，带着别人飞就好了。
分歧
Martin稍微冷静了下，拿过键盘，继续开始修复问题。Ben这时候在一旁观察，也适当的休息一下，之前手忙脚乱的按F8、F9的神经也得以缓和。
Ben：看来还是不行。我们再理一下代码吧。
Martin：你说的这些我之前都试过，都不行，要这样才行。
Ben：我说的是这样做的，既然我们还没讨论清楚，我们再来看一下代码吧。
两人拿出了纸和笔，对着屏幕一边画一边讨论，然而Ben并不认可Martin的方案，说要采用另外个方案。Martin则坚持认为这是一个可行的方案，得试试。Ben拿过键盘，准备按照Martin的方案写代码，但心里面颇为不爽，一直在想说服Martin采用他的方案试试。
怒气
到此时，时间都已经不知不觉过去两个小时了，然而问题似乎离真相总是忽远忽近。两个人已经疲劳不堪，再加上解决方案的不一致，两人的言语中开始显露出一些怒气。
Zen在运行测试的空档，打断了两人的对话，建议道：
既然大家已经产生了分歧，要不然两个人分开，各自实现一个，看谁能够先实现，然后再来讨论。
Martin对于Zen并不认同，认为Zen指责他和Ben没有Pair好。
Zen解释道：
其实我听出了两人意见的不统一，言语中已经有一些怒火，这样下去Pair的效率很低。首先，大家带着不爽来干活，互相质疑。更关键的是，解决问题已经用去了两个多小时，大家都比较疲惫，可以适当休息。我让你们分开的目的是让大家冷静一下，在不受打扰的情况下工作一段时间，可能会不一样。
冷静
Martin回到了电脑面前，按照他的思路一步一步做下去。Ben去上了个厕所，倒掉了那杯冷冰冰的咖啡，泡了杯热茶。回到电脑前专注的重新按照他的思路一步一步走下去。
其实两个人已经接近了真相，只是这之间不停的对话把注意力消耗殆尽。两人企图达到一个统一，然而口头的对话并不能解决问题，反而暂缓了这个过程。
10分钟后，Ben兴高采烈的说已经搞出来了一套可以运行的方案，叫Martin一同过来看看。Ben的临时解决方案比较简单好理解，但并不完美。熟悉RxJava的Martin指出了一些可以改进的地方。
然后两人又开始了新一轮的Pair，重新将这个方案完善。有了这个基础的解决方案，两人都很高兴，是朝着一个正确的方向大步向前。
尾声
下午6点半，虽然比正常下班晚了半个多小时，但还好整个解决方案都正常了，交付的任务也顺利完成。
Ben和Martin都总结道，我们应该停止结对，当：
- 两人的思路不统一但无法说服对方时：我们可以考虑分开一阵，安静一下，各自用可运行的代码来证明思路的可行。这里只需要相对粗糙的代码即可。
- 时间已经超过番茄时间而感到疲惫时：人的专注力是有限的，在Pair时非常累，特别是在能力方面存在较大差距的时候。在这时候我们可以试试番茄工作法，让大脑得到休息。
- 注意力不集中或者有其他事务要处理时：在Pair的时候，彼此要尊重对方，不要玩手机、看其他无关的网页，除非事先取得别人的同意，否则就要等到停止结对、处理完事务后再继续。
