没有同理心

编程入门行业动态更新时间:2024-10-14 08:25:07

没有同理心

几乎可以肯定，对Linus Torvalds这个名字不熟悉的软件开发人员对他的工作很熟悉。由于他是Linux内核和Git（这是现代软件和计算中最重要的两个项目）的作者，因此被广泛认为是世界上最多产的软件开发人员之一。

不幸的是，他也以对同事的侮辱性语言而闻名。在2018年9月，Torvalds宣布他正在休假领导Linux项目。在致维护者的一封致歉邮件中，他提到他将“获得一些有关如何理解人们的情绪并做出适当React的帮助。”

Torvalds的不良行为助长了长期存在的刻板印象，导致人们在社交媒体上提出疑问，例如“ 为什么大多数程序员很奇怪？他们似乎没有任何社交技能。 ”和“ 为什么编程具有如此多的负面刻板印象？ ”。如果您查看围绕软件开发人员刻板印象的大多数负面印象（反社会，过分技术，居高临下），则许多劣质源于缺乏同情心。

在较高的层次上，同理心只是将自己置于另一个人的脚下，感受他们的感受并想象遇到问题和目标的感觉的能力。除了极少数的例外，我们人类都本能地感觉到同情，但是通过注意同情很重要的情况，我们都可以发展这种至关重要的素质。

在硅谷主要的技术公司任职软件开发人员的那几年，我发现同情是最被低估和最重要的技能之一。这是您在工程师职业生涯中可能会产生的同情心：

同情其他工程师

资料来源： XKCD

除非您是团队中唯一的工程师，否则几乎可以肯定，您将花费大量的时间以技术讨论，设计文档以及最重要的是代码审查的形式与其他工程师进行交流。根据团队的规模，所有这些交互很容易成为工作中最耗时的部分之一。

请注意，即使对您的评论做出响应并为您进行代码审查是同事工程师工作的一部分，但要求他们的投入本质上是在要求他们花费时间。您不仅在询问他们的时间，还要求他们放开他们的计划，扰乱他们的流程。因此，将帮助您的时间和来回交互的次数最小化是很有意义的。您如何最好地做到这一点？

1.做自己最严厉的批评家

您刚刚编写了一些代码，并且即将要进行审查。但是，等等，谁应该是第一个对此进行审查的人？您！

我无法数出某人向我发送过一次代码审查的次数，并且在我阅读的前几行代码中存在明显的明显问题。如果他们完成了我要我做的事情（阅读他们的代码），这些问题肯定会被发现。在发送任何代码审查之前，请花点时间浏览代码以查找明确的问题。避免别人指出代码中的明显问题是尊重他人时间的关键方法之一。

2.预期同事的问题

我们所有人都不得不提交我们不为之骄傲的代码-可能是迫在眉睫的截止日期或使用粗糙的API会使您做一些可疑的事情。这是＃1的必然结果，但是阅读您自己的代码时，不仅要认真对待问题，而且还会混淆您的同事。

主动记录必须做出的代码质量牺牲以及原因。换句话说，请留下评论（在代码中或在PR中，但是您的团队决定处理评论），并留下您知道审阅者会回答的问题的答案。

3.首先寻求了解

可以肯定的是，您组织中的其他工程师将不同意您的想法。除非您能够单方面做出所有技术决定，否则您仅需接受这一事实并学习如何有效地处理它。

在我职业生涯的早期，我会将分歧和辩论视为人身攻击。与我合作的人都知道我持有强烈的意见。随着我职业的成熟，我意识到，以您的观点（不仅是关于技术，而且实际上是任何事物）认同自己，甚至当有人不同意您的观点时，都会感到受害，这实际上是非常有害的。这种感觉全是关于自我，健康的工程文化几乎没有余地。

如今，我仍然持有坚定的意见，但是我尽最大努力将分歧视为向他人学习的机会。尽一切努力了解您不同意的同事的观点。在表面之下可能是你们两个可以达成共识的目标或前提。问（尽可能不打架）为什么他们持有自己的信仰。你同意吗？如果不是，请继续询问原因，直到您对要达成的目标达成共识，并找出分歧的根源。

这个过程几乎总是从您同事的经验中获得大量信息，如果您从表面上保持分歧，您将无法获得这些信息。如果您的工作环境可以使想法可以公开竞争并且可以赢得最佳想法，那么即使最终结果不是您的想法，这也意味着最终结果对您的团队将是最佳的。就是说，除非您的同事只是教条式的鹦鹉重复他们在Medium上某个博客文章中阅读的内容，否则我永远不会想出如何解决这个问题，我也不知道该如何帮助您。）_ /¯

4.要积极

编程作为一个行业可以被认为是最关键的之一。您会不断地将工作放在那里，以供队友评判。如果您像大多数工程师一样，包括我本人在内，您的代码审查中就会堆满零敲碎打的东西和您需要改进的地方，很少有人会感到鼓舞。在许多方面，处理这种批评只是工作的一部分。我们希望不断学习，成长，并不断追求卓越。

但是，将他人推向卓越并提供积极的支持并不是相互排斥的。您的队友是否正在使用他们正在使用的此功能将其杀死？他们是否清理了不必要的代码库部分作为PR的一部分？他们是否与您一起浏览了800行代码审核？告诉他们，您感激不尽！

关于正面评论与批评的理想比例应至少为5比1的方法已有大量研究。通过提供真诚的赞美来建立信任，可以更有效地帮助建设性反馈。当人们知道您在乎他们时，他们就会知道您的批评来自于试图使他们变得更好，而不是试图将他们推倒。

合法地，这个领域中的某些人并不真正在乎这样的事情，这没关系-但很多人确实如此。我为在一个我们都积极致力于创造一种可以，甚至可以真诚地鼓励彼此的文化的行业中工作而感到自豪。

同情其他团队

您最终也将不可避免地要花费大量时间与跨职能团队合作，例如与设计团队协调以提供其模拟的约束和方向，与产品经理合作以了解规格，与营销部门合作以构建目标页面，等等。当有人提出要求或要求您提供某些东西时，请把自己放在不知道您可能会使用的所有术语和详细信息的人的鞋子上。他们可能希望工程师如何回应？

我发现在交流过程中最有价值的概念是您的受众感兴趣的详细程度。请尽可能避免使用技术细节和行话。了解细节通常不是他们的工作-这是您的。

作为工程师，我们倾向于陷入问题的困扰，在向他人解释问题时，确实很难做到一点点。有时人们对这些细节真正感兴趣，但是如果是这样，那么他们会告诉您。我建议从高层次入手，特别是从他们关心的问题入手，并在他们表示感兴趣时进行更多的解释（并始终让他们知道您愿意谈论这件事）。

首先，请记住，您都在追求相同的目标。希望，如果有人要问您一些问题，这将有助于为您的用户构建更好的产品。与周围的人交流时，请记住这一点。

对用户的同情

资料来源： XKCD

最后也是最重要的一点是，理想情况下，您应该尽可能多地感受到用户的痛苦。我们的用户通常是我们的抽象，被几层交流所隐藏（例如，客户服务->产品经理->我们）。出于多种原因，这种抽象是有道理的-想象一下，如果客户一直与工程师保持直接沟通，那么尝试完成任何事情。但是，当我们被允许避免太长时间考虑用户时，很容易忽略我们在做什么。

您的用户不只是指标

想象一下，您部署了一个破坏关键流程的错误，例如，为一小部分用户（例如2％）下载应用程序中的数据电子表格。如果您是一家数据驱动的公司，则您和您的团队可能会查看指标，并发现人们已经无法完成此流程。您查看使用情况后会说：“哦，人们并不经常使用此功能，只有2％的用户使用。我们将尽快解决它，但现在还有其他优先事项。” 但是，这种流程可能会让这2％的用户完成工作，并且您可能同时完全破坏了他们有效使用产品的能力。

我知道将少数人的痛苦摆在许多人的愿望/需求之前是不可能的，我并不是在建议您的团队需要完全改变他们的方法。关键是永远不要忘记在这些屏幕后面有人类。也许您的团队的目标会因此而改变，也许不会改变，但是

优先考虑消除客户的痛苦并不是一件抽象的好事-产品通过倡导而生存和消亡。如果您中断了此功能并且不太在乎，那么您认为这些用户如果朋友或同事问他们对您的产品有什么看法呢？

为不同的用户建立同理心

我不会做太多的事情，因为用户体验（UX）本身就是一个完整的领域和工作职能，但是在这里值得一提的是，培养同情心也会为您的用户带来更好的产品。我们的软件倾向于使用户的生活更轻松。我们都应该努力使它尽可能简单直观。

还请记住，您的用户可能与您完全不同。想象以下几种情况，如何以不同的方式构建产品：

您是发展中国家的用户，需要按兆字节付费
您是视力不好的用户，不能很好地看到色彩对比，或者是行动不便的用户，只能使用键盘进行导航
您是一个不太精通技术并且很难导航复杂交互的用户

要真正让自己陷入与您或您认识的人截然不同的人的脚上，将是非常困难的，甚至是不可能的。这就是为什么许多这样的问题通常在不同领域（例如用户研究和UX设计）解决的原因。但是，即使您有幸与这些领域的人一起工作，也不会让您摆脱困境。如果您对这些问题负责，而不是让跨职能合作伙伴考虑这些问题，那么您的产品会更好。