代码与善意

作者：Max Kanat-Alexander
日期：2017年8月12日

很容易将软件开发视为纯粹的技术活动，认为人类无关紧要，一切只关乎计算机。然而，事实恰恰相反。软件工程本质上是一门关于人的学科。

多年来，许多试图修复软件开发的错误都是因为只关注系统的技术方面，而忽略了编写代码的是人类这一事实。当你看到有人更关心优化而非代码可读性，当你看到有人不愿写注释却花一整天调整 shell 脚本以减少行数，当你遇到无法沟通却崇拜小二进制文件的人时，你看到的是这个问题的各种症状。

实际上，软件系统是由人编写的。它们被人阅读、修改、理解或不理解。它们代表了编写它们的开发者的思维。它们是地球上最接近原始思维表达的形式。它们本身并不具备人性、生命、智能、情感、邪恶或善良。这些品质属于人。软件完全且仅用于服务人类。它们是人的产物，通常是那些必须合作、沟通、相互理解和有效协作的一群人的产物。因此，关于与一群软件工程师合作的一个重要点是：在开发社区中对他人残忍毫无价值。

对与你共事的人粗鲁无济于事。愤怒地告诉他们错了，不应该做他们正在做的事情也无济于事。确保应用软件设计法则，让人们遵循一条好的路径，制作易于阅读、理解和维护的系统，这才有帮助。然而，这并不要求你残忍地去做。有时你确实必须告诉人们他们没有做对的事情。但你可以实事求是地表达——不必当面指责或人身攻击。

例如，假设有人写了一段糟糕的代码。你有两种方式可以评论这一点：

• “我不敢相信你认为这是个好主意。你读过软件设计的书吗？显然你不该这么做。” 这是粗鲁的方式——是对个人的攻击。
• 另一种告诉他们问题的方式是： “这行代码很难理解，这看起来像代码重复。你能重构一下让它更清晰吗？”

在某种程度上，关键点在于你是在评论代码，而不是开发者。但同样，关键点是不要做个混蛋。我的意思是，拜托。第一种回应显然是粗鲁的。它会让那个人想和你合作、贡献更多代码或变得更好吗？不会。另一方面，第二种回应让那个人知道他们走错了路，而你不会让那段糟糕的代码进入代码库。

你阻止那个程序员提交糟糕代码的全部原因首先与人有关。要么是关于你的用户，要么是关于其他必须阅读系统的开发者。通常，两者兼而有之，因为制作一个更可维护的系统完全是为了你能继续有效地帮助用户。但无论如何，你作为软件工程师的工作与人有关。

是的，很多人会阅读代码和使用程序，而你审查代码的人只是一个人。所以可能会认为，为了让这个系统对每个人都有好处，你可以牺牲一些善意。也许你是对的。但为什么在不必粗鲁或残忍的时候要这样做呢？为什么要在团队中创造那种让人们害怕做错事的环境，而不是让他们为做对事感到高兴？

这不仅仅限于代码审查。其他软件工程师有话说。你应该倾听他们，无论你是否同意。礼貌地承认他们的陈述。以某种建设性的方式传达你的想法。

而且，看，有时人们会生气。要理解。有时你也会生气，你可能希望你的队友在你生气时也能理解。

这一切可能听起来有些空灵，像某种不重要的心理废话。但看，我不是在说“每个人总是对的！你应该一直同意每个人！永远不要告诉任何人他们错了！没有人做过任何坏事！”不，人们经常犯错，世界上和软件工程中有许多坏事你必须拒绝。世界并不总是一个好地方。它充满了愚蠢的人。其中一些愚蠢的人是你的同事。但即便如此，对那些愚蠢的人粗鲁也不会做任何有效的事情。他们不需要你的仇恨——他们需要你的同情和帮助。而你的大多数同事可能不是愚蠢的人。他们可能是聪明、善意的个体，有时会犯错，就像你一样。给他们怀疑的好处。与他们合作，保持善意，从而制作更好的软件。

• Max

评论

Nemo 说：
2017年8月12日下午1:27
你的推理有一个明显的缺陷。你在电梯里遇到某人，你礼貌而友善。这个人踩了你的脚一次，你礼貌而友善。第三次这个人踩你的脚时会发生什么？第五次呢？情况a.你是个圣人，死时礼貌而友善；情况b.你只是凡人，在某个时刻你不再礼貌而友善。因为你知道，有人一直踩你的脚没有很多原因，实际上只有两个：这家伙要么愚蠢要么坏，两种情况下他都危险。是的，你可能也有异常长的脚，所以这家伙不动就会踩到一只。我猜在这种情况下你不能和任何人一起在电梯里，所以推理再次不适用。

回复

Max Kanat-Alexander 说：
2017年8月12日下午2:50
不。这里的评论似乎没有抓住重点。
首先，你的 fellow 开发者没有踩你的脚。他们没有造成你身体上的痛苦甚至攻击你。没有理由你对糟糕代码或困难技术讨论的反应像对实际身体攻击你的人一样。
其次，再读最后几段，意识到我说了你应该阻止人们做坏事。我不知道你在这里提议做什么能实际解决问题，除了比如在某个时候报警？我看不出这些如何证明对同事粗鲁是合理的。

• Max

Nemo 说：
2017年8月13日凌晨1:04
我和许多“ fellow ”开发者共事过，他们踩了我的脚。根据我的经验，发生这种情况是因为除了人们常见的所有问题外，开发者平均而言在与他人关系和扭曲人格方面有严重困难。
有无数的例子。相对有趣的比如你向客户演示新产品，你激活某个功能，却得到经典的“演示灾难性错误”，但你不是在大屏幕上显示“lorem ipsum”文本，而是一连串的脏话。真正糟糕的比如客户打电话因为服务器宕机或软件以某种方式崩溃，而你不在办公桌，你的“ fellow ”开发者在那里玩纸牌或看色情内容，不接电话。或者你必须协调在同一软件的不同部分工作，而你的“ fellow ”开发者故意拒绝同意如何做事，反而努力让你的部分尽可能困难，直到整个项目失败，只是为了享受。更不用说你的“ fellow ”开发者从雇佣你们俩的公司偷东西，一直说谎，伪造分析，试图偷你的工作或试图为你的成就邀功等等。
此外，这不仅仅是关于工作，当你看看整个“开源”生态系统，Linux 之类的东西，你可以轻易看到人们一直互相踩脚，没有其他原因，只是许多人要么愚蠢要么坏（你可以两者兼而有之，仍然能编码）。
老兄，你生活在幻想之地。

回复

Max Kanat-Alexander 说：
2017年8月13日凌晨4:17
我明白你说的一切，Nemo。
听起来你只是在说人们经常很坏。也许这是真的。但这不需要粗鲁来修复。你甚至不必在解雇某人或向人力资源和管理层写关于他们行为的报告时粗鲁。
注意，听起来你一直处于一个人们一直很坏的环境，所以也许你到目前为止所做的关于它的事情实际上没有奏效。你考虑过这种可能性吗？

• Max

Joe G 说：
2019年9月30日下午3:33
Max – 你的思维与我共鸣，一直是我在软件开发中的座右铭。阅读评论后，很明显不是每个人都同意。我的观点已经转向“开明的自我利益”观点，即对他人友善、不故意伤害他们符合你自己的最佳利益。有很多方式我们无意中造成伤害，比如犯简单的错误，别人不得不花几个小时修复。对我们行为的正念，对我们编码宇宙中的人的共情，以及只是在乎我们做什么——很重要——并以善意回报我们。

回复

Max Kanat-Alexander 说：
2019年9月30日下午4:16
太棒了，Joe。我认为说得很好。

• Max

Darren S 说：
2017年8月28日下午3:15
我认为作者试图表达的观点是，你对坏/负面事件的反应应该引导互动/环境向积极方向发展。如果有人踩了你的脚，积极的反应会是像“对不起，但你踩我的脚很痛，我不确定这有什么目的，你能解释一下吗？”。
我也和难相处的开发者共事过，我曾经有这种“我不是负面，我是诚实”的态度。但那仍然是负面的，我最终 learned 如果我想让其他人改变态度，我能做的只是成为一个积极的影响，句号。
相信我，我有过初级人员犯严重错误，让公司损失金钱。非常令人沮丧，尤其是在你事先解释了如何避免那些错误之后。但指责人总会引发负面反应，即使他们不立即表现出来。
你似乎专注于事情的负面方面，没有提供任何解决方案。这正是我提到的初级开发人员作为高级开发人员难以共事的原因。一旦我以开放对话回应，而不是指责，我开始看到他的反应变化，我们开始讨论而不是争论。
我认为这是作者在这里的观点，有毒环境中的积极改变必须从积极（或至少建设性）的对话开始。指出失败而不提供解决方案毫无成效。如果有的话，它会产生负面效果，使初始问题更糟。

Mike W. 说：
2017年10月30日下午3:47
留在你的例子/类比中，你不必粗鲁地对待他来防止他踩你的脚。句号。
事实上，粗鲁地对待他不会阻止或劝阻他踩你的脚。这是“惩罚驱动心理学家”犯的错误：如果你非常非常用力地踩他的脚，它会“教”他坏事情发生当他踩你的脚时，然后他就不会再做了。或者如果你对他尖叫说他是混蛋因为他踩了你的脚，那么他会通过惩罚“学习”再也不会踩你的脚。这个理论行不通。（如果你不相信我，下次有人推挤你或踩你的脚时可以试试。对他们尖叫足够多，你可能会挨一拳。）
相反，正如这篇文章最后一段描述的，你可能会（冷静地）大声说，“嘿，伙计，你能请更仔细地看你在哪里走路吗？你刚踩了我的脚。”这比粗鲁更可能有效。
你设置了一个完全错误的二分法，陈述一个人要么愚蠢要么坏。你有没有想过，当你以那种信念对待他人时，他们自然会对你反应不好？而他们对你恼怒或怨恨的行为 then 可以被你解释为证明他们愚蠢或坏的证据：一个自我确认的假设。试着以你希望他们对待你的方式对待他人，你可能会发现他们对你的行为也改善了。

Nadav Naor 说：
2017年9月12日上午7:43
我相信文章最后的陈述“与他们合作，保持善意，从而制作更好的软件”是这里最重要的陈述之一。归根结底，你希望你的团队成功，你希望你的产品/服务成功，你希望花时间做有影响力的事情，而不是仅仅因为现在添加更多功能太复杂而重构/重新设计旧代码。如果你看到你的一个同行在代码审查中需要纠正，无论是设计方面、可读性还是其他任何方面，你反应越理智和逻辑（而不是情感），你的同行接受你的审查的机会就越大。此外，有时对方有比你更多的上下文。所以即使某些东西看起来不对，它实际上是正确的事情。通过粗鲁，你可能会 later 出丑。试着理解是否有好的理由为什么对方以那种方式编写代码。无论如何，感谢好文章。

Aleksandra Reszotnik (https://www.statlook.com) 说：
2017年9月14日凌晨1:55
感谢文章，我非常欣赏！老实说，我希望生活在一个关于遵守某些文化标准的文章不会作为相当明显的事情而受欢迎的世界。不幸的是，我们不是；我想不出任何对他人 simply 粗鲁的解释。无论如何，趋势在改变，也由于像你这样的声音——我很高兴见证这一点。

Nexle 说：
2017年10月3日晚上8:10
我同意作者的观点。看看软件如何工作，而不是批评它的代码。

Saim Aksr 说：
2017年10月19日下午5:30
我也同意，团队成员应该总是互相帮助和友善，帮助其他开发者，让其他帮助你。它使成功更容易实现。

Roland Askew 说：
2017年10月29日凌晨1:21
完全同意。
重要的是要外交、支持性和开放。软件工程可能是一个要求高的职业，支持性的同事有助于韧性。这是一条双向街道。
我认为很多归结于每个参与者的态度和情感/自我支持技能。不是一个简单的个性衡量——我随着时间的推移遇到了几个刻板印象的内向、逻辑学家、系统思考者类型，他们像每个人一样有各种风格。
我注意到的导致“残忍”情况的趋势可以包括过度膨胀的虚假自信（见邓宁-克鲁格效应），对障碍或错误的糟糕反应，错误的高自我 chastisement，强烈的自我防卫（保全面子是一个例子），“被动优势”效果借此其他开发者习惯更高表现者承担更高工作量并抵制受影响的同事寻求的变化（一种边界 crossing），差的人际成熟度和技能包括 crossing 边界，将不专业的习惯带入工作场所，等等。
人们选择职业可能是因为他们避免什么 as much as 他们提供什么。花时间在只有机器的后室的刻板印象仍然存在一定程度，不幸的是在可预见的 time 这个职业仍然会吸引并允许只想这样做并避免人类关系的人，或者甚至技术辉煌但没有任何人软技能 measure 的人。
我想补充一点，人们有极限，有时储备被职业的压力或需求耗尽。礼貌仍然重要，尤其是对客户，但对过度压力的团队成员多一点理解和宽容大有帮助。为此，公司通过好的员工增强、支持和保留计划做得更好。显然一些现有公司仍然相信不是他们的责任。

Mike W. 说：
2017年10月30日下午3:35
坦率地说，如果你没有以“完全同意”开始你的评论，我会不知道你在这个话题上的立场，尽管我读了你的评论四遍。似乎心理学术语的 sprinkling 并没有帮助有效传递理解或信息给你的观众。
就个人而言，我更喜欢清晰 cut 的工程风格陈述，具有精确和特定的含义，即使讨论与我们职业的人类而非技术方面相关的主题。例如，作者的陈述：“在开发社区中对他人残忍毫无价值。”这是一个具有确切含义的陈述，只需要理解所用英语单词的普通意义。（并注意我不是所有陈述必须可简化为数学中的数字含义以具有逻辑有效性的 notion 的支持者。符号逻辑是表达精确想法而不失去 nuance 的远比写得好的英语更弱的工具。）他的也是一个我相信字面真实且非常有意义的陈述。
further 读了你的评论三遍后，似乎它的意图会被保留、增强和澄清（很像当应用代码简单性原则时的程序代码），如果一个人重构它 simply 陈述：“善意是在 oneself 中保持的最重要品质之一，尽管在尝试这样做时可能遇到许多困难和 discouragements。”
这也避免了未定义的“心理废话 BS”的鼠巢，它经常阻碍关于我们职业人类方面的有效沟通——并 actively 赶走那些更喜欢数据以更有序格式的技术人员。

Eshwar Yaddanapudi 说：
2017年11月11日上午10:06
我几乎几个月前在我的博客 http://www.yesprasad.com/2016/10/passion-and-compassion-your-companions.html 上写了同一个话题。它谈论每个人在办公桌需要的激情和同情。

留下回复取消回复

联系 关于 书：理解软件 书：代码简单性

输入您的电子邮件… 订阅

Max Kanat-Alexander
7月28日
非常兴奋地宣布我将在2025年开发者生产力工程峰会上发表主题演讲之一。我将谈论什么造就了伟大的开发者体验。我自1995年以来一直在技术领域工作，自2004年以来几乎全职从事开发者体验。有一些基本的、普遍的真理关于如何使开发者体验伟大，我将尽力在有限的时间内覆盖尽可能多的内容。希望能见到你。:)
阅读更多
89 11 分享

Max Kanat-Alexander
6月27日
我目前认为AI代理可以成功生成的输出数量和质量取决于：

1. 模型的质量。
2. 代理的质量。
3. 输入的质量（如提示或其他上下文）。
4. 代理可以独立运行的确定性、客观验证的质量。
   我目前认为，除非你是模型开发者，最重要的部分是“确定性、客观验证”。
   简单来说，如果你告诉AI做某事，它需要某种方式能够验证它做了正确的事情，靠自己。在软件中，这通常意味着运行测试、linter等，如果系统做错了就会失败。
   这意味着你的测试和验证工具越好，你从模型得到的输出就越好。不仅仅是测试数量。它们必须是好的测试，具有智能断言和好的错误消息。
   这也意味着代理成功涉及思考如何将任务分解成可以各自通过自动化测试、linter等客观验证的单独部分。
   作为说明，输入的质量也很重要并在我们控制之下。如果我们写更好的文档和更清晰的代码，代理做得更好。令人惊讶的是，几乎一切帮助人类编写代码的东西也帮助代理。
   阅读更多
   20 10 分享

Max Kanat-Alexander
6月4日
技术债务有价值的想法 mostly 是一个神话。当你做出糟糕的软件工程决策时，它会在几小时、几天或几周内减慢你的速度。那是上限。许多人认为需要几个月或几年才能看到在软件设计上偷工减料的影响，但那 simply 不真实。它几乎立即开始。做正确事情的代价通常是几小时，也许一天，而你几乎总是立即 recover 那个时间。也就是说，做对通常花的时间与做错花的时间相同。“等等，什么？那怎么可能？我们偷工减料是为了节省时间！”它几乎总是结果根本不节省你时间！它使处理变更更混乱。它使代码审查更长。它在测试期间以更混乱的方式失败，需要更长时间调试。它几乎从不节省你实际时间。
偶尔，你路径上有一些“岩石”如此巨大，你 simply 无法移动它。没有人应该花三个月设计一个新工具 just so 你可以发货一个一天的功能，一次。但那是技术债务决策的 tiny, tiny 一部分。
这变得更疯狂，因为如果你随着进行做对一切（你总是重构系统 so that 它看起来像是设计来做 exactly 它现在做的事情）那么一切保持相对容易整个时间。但如果你偷工减料，一切变得复合更困难，到点你生成“岩石”没有人能移动。不像复杂性是某种线性东西你可以 later 回去投资线性时间修复。你绝对可以让自己陷入一个如此糟糕的情况，你公司中没有人有时间或专业知识修复它。
这一切感觉如此无辜：“让我们 just 偷几个工减几个料，它会帮助我们 meet 这个截止日期，”（一个截止日期通常是虚构的 anyway，你可以滑几周没有后果）。“很难弄清楚如何做对这件事，我们可以拖延它吗？”然后 bam，非常快你发现自己陷入沼泽，一切困难且“我们不知道为什么！”
我留给你最后一件事：当我直接编码我生活的每一天时，