【译文】软件工程中的软技能

前言

如果你正在经营一家公司,”我们需要重构这个模块。”这句话你肯定不愿意听到。除非你是技术出身,否则这句话毫无意义。事实上,这是一个可怕的说法,因为这意味着你需要改变一些之前以某种方式运行的东西。正如肯特-贝克(Kent Beck)在他的著作《整洁第一?一书中解释的:”没有新功能,可能会造成损坏,而且最后什么也得不到。不,谢谢”。

管理者了解问题空间、领域以及如何管理组织,而不是技术实施细节。他们并不关心你在 Livewire 中使用的是 Next.js、React、Symfony 还是 Laravel。对于用户来说,这也是一个有效的说法。他们不关心技术实现;他们关心的是服务。

管理者负责在特定领域获得市场份额。他们优先考虑的是能够可靠运行并满足最终用户需求的产品。然而,当工程师与商业世界的现实脱节时,问题就出现了。我们期望经理们能理解我们的技术观点,甚至在他们不理解时感到失望。我们希望他们理解 “我们需要重构这个 “的意义。因为这对我们来说真的很重要。如果你的经理是工程师出身,那就再好不过了!今天,我们将讨论另一半,即经理和工程师脱节的情况。

为什么管理者不理解软件工程师?

因为我们不知道如何解释自己。我们拘泥于技术术语。我们所说的 “重构 “或 “技术债务 “等术语对大多数人来说毫无意义。他们不懂如何取舍。如果一项任务可以快速完成,我们就应该快速完成它。我们不应该再说:”是的,我可以尝试在一周内完成,但这真的很难”。这就意味着,如果你不能在一周内完成任务,你就不是很努力。所以,你只是给自己制造了一个问题。我们经常无法进行有效的沟通,因为我们不太考虑自己的语气。我们没有努力去了解业务是如何运作的。因为我们拘泥于技术细节。我们没有时间去思考我们的用户、我们的业务以及他们的需求。我们无法提出非技术性的解决方案。我们看起来不专业。

我想说明的是,这并不是对工程师的攻击。事实上,在我职业生涯的早期,我也曾处于同样的境地。这只是一种诚实的自我批评。我感到沮丧的是,似乎没有人理解重构的重要性。

让它变得重要:它不仅仅是糟糕的代码

我们需要解释的是,如果我们投入一些资源来重构有问题的模块,就可以腾出精神空间来关注产品的其他方面。然而,这不应该仅仅是技术原因。我们应该提供对所有人都有意义的其他合理理由,而不仅仅是开发人员。

很难维护不是一个论点。你的工作就是维护它。难不难并不重要。对你来说很难,而不是对业务的另一方来说很难。只有当你让它变得重要时,它才会变得重要。许多工程师都很难理解这部分内容。他们知道有问题的模块会损害业务。但是,他们不知道如何用非技术语言来表达这个问题。我们需要找到一种大家都能理解的共同语言。我们为什么不用实际数字来表达呢?比如

我们必须重构预订模块,因为它不仅难以维护,去年还造成了 11 个中度错误和 2 个严重错误。严重 bug 造成的损失超过 47500 美元,中度 bug 造成的损失约为 43000 美元。我们总共收到了 197 份用户报告,其中一个错误甚至造成了严重的安全问题,可能会导致法律后果。我们已经制定了一项具体计划,将在未来两个月内对这一领域进行重构。我们将组建一支由 3 名开发人员组成的工作团队,每人负责不同的领域。您可以在下面找到该计划和详细列表。这两个月的重构工作将在今年为我们节省大约 65,000 美元,明年也几乎是同样的数额。这不仅能解决当前的 bug,还能改善用户体验 (UX),帮助我们快速解决未来的问题。目前,即使是小问题,我们也要花费大量时间。预订模块目前就像一个迷宫,让每个人都很难进入。我们可以把精力投入到开发新功能上。

这和说 “我们需要重构这个 “感觉不同,不是吗?当然,写一句话要花费更多的精力,但如果把所有的抱怨加在一起,可能会花费更多的时间。不要说维护它很难。解释它是如何损害你的业务和用户体验(UX)的。试着设身处地地为企业和用户着想。解释每个人如何从这一改变中受益。管理者可能很难理解,为什么一个盈利的企业要花时间去修复一些赚钱的东西。

抱怨与解决问题

软技能对于创造美好的职业生涯和人脉关系来说非常宝贵。如果你无法解释自己,就没有人能理解你和你的问题。你有责任让别人理解你,而不是理解他们。这句话同样适用于你的个人生活。你是真的想解决问题,还是想抱怨?抱怨可能会让人感觉很方便,但它只能提供暂时的缓解,而不能解决实际问题。我有过这样的同事,他们每天一进办公室就抱怨一切。他们希望每个人都能理解自己的问题,却从不去理解别人的问题。老实说,我并不怀念与消极的人共事的日子,他们总是抱怨,却不试图解决任何问题。他们只会传播负面情绪。你不应该成为这样的人。抱怨解决不了任何问题,包括你的问题。

有些人倾向于抱怨,但他们也试图找到解决方案,更好地了解情况。有时感到不知所措和抱怨是完全正常的,尤其是当你关心某件事情并想要改善它的时候。我想说的是,在表达你的不满时,你应该保持逻辑性和客观性。也许你面临的问题并不只是你一个人的问题,你也不一定非要自己解决。寻求帮助是完全可以的。但请记住,只抱怨而不采取任何行动对任何人都没有帮助。

交流

我们使用计算机和代码来解决问题,但我们解决的不是计算机问题。归根结底,我们是在解决人类的问题。计算机不是我们的客户。沟通和联系永远存在。如果我们与客户、团队和经理脱节,就无法理解我们需要解决的问题。我们应该专注于实际问题,避免沉溺于技术细节。这就是为什么理解和实践领域驱动设计(DDD)和测试驱动开发(TDD)会有所帮助。我们会更加关注实际问题,而不是仅仅关注实现细节。有效解决问题需要沟通。这也是公司、经理和其他人正在寻找的,他们正在寻找能够沟通的问题解决者。

表达思想的能力

你能向世界表达什么,你就是什么。你能解释多少,别人就能理解你多少。我们中的许多人都曾有过这样的经历:我们知道一些事情,但却无法用语言表达出来。这甚至让我们怀疑自己是否知道那件事。出现这种情况通常是因为我们难以表达自己的想法。有时,只是缺乏理解或词汇。有时,对方没有技术背景。有时,我们不知道如何简化。我们不知道如何将概念抽象化。你需要组织你的想法,让它们清晰明了。要以结果为导向。如果你在解释你所知道的和给你带来麻烦的事情时遇到困难,也许是时候开始多读多写了。你不必与人分享。写作是一种很好的放松方式。在白纸上解释自己,最终会有助于向别人解释自己。你会明白自己的声音是怎样的,并找到让它变得更好的方法。它可以让你与自己进行头脑风暴。

建设性自我批评

我们的个人生活和职业生涯受到自身诸多方面的影响,这一点很难接受。我们很难接受自己、队友或合作伙伴之外的影响。没有人教过我们这项技能,也很难理解。有时,我们会不断地评判自己,这可能会成为一种不健康的习惯。但一般来说,我认为建设性的自我批评是一种有效的工具。我关注的是我可以改变的行为,而不是全局性的、无法改变的问题。此外,我不考虑感受,而是优先考虑结果。这些结果不仅会影响我自己,还会影响其他人。你不需要对自己咄咄逼人,而是要从他人的角度来理解情况。建设性的自我批评给你空间和理解。这是一种帮助我们对自己形成反馈的工具。

你花了几个小时开发的功能可能不会给产品带来任何价值。你的代码审查可能只是在阻碍其他开发人员,而不是提供建设性的反馈。如果你总是脾气暴躁,可能会让别人不想与你共事。如果你总是没有同理心地催促别人,你可能就不是最好的领导者。这就是理解和换位思考。

结论

当然,外部因素也会影响我们的工作。有时,管理者不具备管理团队的技能,或者很难与之共事。还有的时候,他们可能缺乏同理心,或者进行微观管理,导致团队难以运作。我完全理解所有这些情况。它们是常见问题。这篇文章不是针对它们的。而是关于你的个人成长。如果你想打造最好的自己,就不应该只局限于技术技能。你应该培养沟通和解决问题的能力。不要让外部环境限制你的潜力。

本文文字及图片出自 Soft Skills in Software Engineering

余下全文(1/3)
分享这篇文章:

请关注我们:

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注