作为使用结对编程的开发者，我自己的的经验是这样的，它并非只是一种一个人编码，另一个人观察的技术。两个程序员会很紧密地在一起工作，总是在交谈，快速记下对要做的事儿的提醒，并且在屏幕上指出代码的片段。（结对编程的特征之一就是，如果你正确地使用了这种方法，那么在一天结束的时候，屏幕上会满是油腻的手指印。）程序员轮番使用键盘，经常会用这样的话来进行交换，“不，让我向你展示一下我是什么意思。”
以他对有效的结对编程的描述为基础（并且指出并非所有对结对编程的实现都是有效的），他提出了能够使有效的结对编程变得成功的四种机制。
机制一：结对编程者的交谈
Brian Kernighan和Rob Pike建议要大声地解释问题，即便是向毛绒玩具也要那样，John正在研究的一种实践叫做“橡胶植物效应（rubber-plant effect）”。结对编程的一部分效力是由于持续触发这种效应而得到的：当一位程序员被卡住了，那么反复的交谈会使其突破，这种方式与单独工作的程序员大声地说出自己的问题是类似的。
他还讨论了交谈带来的更大的好处，其中应用了他所谓的“专家程序员理论”——随着需要知识的问题被更有效地解决，结对的两个人会彼此更了解对方。
那么这可能正是专家程序员理论起作用的地方：专家更可能会提出有深度的问题，那会对被卡住的程序员起到很大的提示作用。看起来还可能仅仅是认为你正在与一位专家交谈——或者假装——那会帮助被卡住的程序员得出那种有深度的问题，可能在之前专家曾经问过他们。
将交谈的价值累加起来，他指出：
这样，第一种机制让我们可以猜测，对程序谈论更多的程序员会更有生产力，而不时地互相提出有深度的问题的人会是生产力最高的。
机制二：结对编程者会注意到更多细节
“你看不到自己的错误”，这是软件开发中的（也是很多其它学科的）公理。
Wray将这与改变视盲和无意视盲理论相关联。
我们所能注意到的东西取决于我们期望看到什么，以及我们无意识地认为突出的东西。所以，尽管成功的结对编程者通常更多地会关注同样的东西，但是他们也可能会注意到不同的东西。
因此，一起编程的两个人不会擅长同样的知识或者类别：一个人可能会更快地指出某个方面的问题，而另一个人对于其他方面更快一些。这样他们的工作效率就取决于他们通过观察来找到问题的速度。两个人的头脑肯定会比一个人的好。事实上，当人们开始进行结对编程的时候，最早做出的发现之一就是，不输入代码的人总是会更快地找出拼写错误：“哦，在这里你漏掉了逗号。”
接下来，他提出了关于结对疲劳现象的警告：当两个程序员进行结对，他们发现和无法发现的东西会变得越来越类似。最终，两双眼睛的优势会丧失殆尽。
结对疲劳使得我们经常对结对进行轮换：
有些结对编程者认为轮换是实践中可选的部分，而且在小型团队或者是没有几个程序员愿意结对的团队中，可能没有其它的选择。但是，结对疲劳意味着最终他们的生产力会降低。
机制三：与不好的实践作斗争
由于来自同侪的压力而不使用不好的实践，有人已经明确地指出这是有效的结对编程的优势。
他讨论了“编码并修正”编程的例子，并将它与老*虎*机赌博成瘾相关联。
这是交互编程特定的属性，使得我们很难做正确的事情。使用编码并修正的方式，我们会随意的修改程序，每次运行代码的时候，就像将硬币放在老*虎*机里面一样。老*虎*机是我们所知道的最容易上瘾的一种赌博形式。而来自于“编码并修正”编程会带来类似的不可预测的好处，这意味着它同样让人容易上瘾。
而结对编程比较不容易受到不好的实践的影响，因为程序员们会承诺以特定的方式编写代码，并确保两个人都信守承诺。在人们容易犯错的工作中，两人结对工作的方式变得越来越流行，这会让我们认真考虑，结对的压力也可能是我们的一种解决方案。
机制四：分享并评价专家的意见
个人的生产力之间会有巨大的不同，至少可以将其分解成十个因素来度量。这通常意味着对难度和时间的估计是不准确的。对于好的和坏的程序员都是这样——你只能通过与其紧密地工作来确定一个人的编程能力。
大多数程序员会解决他们自己的问题，因此没有人知道他们有多棒（或者有多糟糕）。但在结对编程中，人们持续地一起工作。因为他们会不停地交换搭档，团队中的每个人都知道对于特定的领域谁是最专业的。出于这种比较，他们也会意识到自己的专业等级。这样我们应该期望，比起单独的编程团队，通过结对编程可以对时间和难度进行更准确的估计。从我们的经验看，这的确是那样的。
