原文链接: https://leaddev.com/soft-skills/what-makes-effective-software-engineer
成为一名优秀的软件工程师,和成为一名高效的工程师,并不一定是同一件事。在这篇文章中,Google 的 Addy Osmani 总结了高效软件工程师的十个关键特质。
对软件工程师来说,高效之所以重要,是因为它能让我们把时间聚焦在真正重要的事情上——也就是为我们所拥有的时间,向用户、业务,以及最终向我们自己的职业,交付最大的价值。如果我们的精力集中在那些被认为最高效的活动上,我们也能向团队证明自己的价值,从而增加晋升和职业机会的概率。
在这篇文章中,我会结合自己在 Google 的经历,分享我对"什么造就了高效工程师"的看法。
作为一名软件工程师,你应该关心你的用户,关心他们想要什么。你应该能够理解公司的目标,以及你的工作将如何影响这些目标。因为你最终的责任,是构建出用户愿意付费来解决的软件问题。如果你不思考人们将如何使用这个产品或服务,那么你正在构建的东西很可能根本没人用。
虽然这听起来显而易见,但对很多开发者来说其实很难做到。我们经常看到开发者陷在写代码的细节里,却没充分想清楚自己为什么要写这些代码。这会让他们偏离真正的目标,也会因为只关注小任务、而没有为更大的战略成果做贡献,从而远离了自己最好的工作。
以下是让你变得更高效的十种方式。
Caring about the user
关心用户及其需求,是高效软件工程师的核心。这比掌握某项具体的技术或框架更重要。一个高效的工程师会考虑:
Being an effective problem solver
你必须擅长解决问题。最好的方案往往是简洁、优雅的。但有时你也需要跳出框架思考。很多时候,一个问题可以用多种方式解决——有些整洁但不复杂,有些虽然不常规,但同样有效。
解决问题的能力,一旦你掌握了工具和流程,任何人都能具备。能够跳出框架思考,同时兼顾问题的方方面面,将有助于确保你的产品或服务发挥出它应有的潜力,让用户满意。
Keeping things simple, while caring about quality
你不需要去写世界上最复杂的软件。你只需要理解问题、知道如何用合理的方式解决它,然后保持简洁。随着行业经验的增长,你会越来越擅长在"简洁"和"性能"之间做权衡。如此一来,你的代码会变得更高效,而不牺牲整体质量。
关于"质量"这件事,表面上看很简单,实际上需要持续警惕。你总是在不同维度的质量之间做平衡(比如无障碍性 vs 性能)。理解在你的产品或服务中什么是最重要的,这一点很关键——这样当多个优先级相互冲突时,你才能在开发周期中做出明智的判断,决定哪一方应当胜出。
Building trust, autonomy, and social capital
逐项来看:
信任(Trust)。信任不是一夜之间能建成的,但你可以日积月累地搭建。很大一部分靠的是可靠和一致。如果有人向你要一个东西,尽量尽快交付。如果你承诺了一个截止日期,就死守它。只要你不在其他方面弄虚作假或不可靠,人们会习惯与你协作,因为他们知道能从你的行为中预期到什么。
自主权(Autonomy)。拥有自主权的员工更快乐,快乐的员工往往比那些对自己工作方式毫无选择权的同事更有生产力。自主权并不意味着一个人可以不顾后果地为所欲为。更确切地说,有效的自主权意味着在"需要做什么"和"团队结构中每个人如何履职"这两个上下文内,给予员工自由。
社交资本(Social capital)。软件工程师天生往往偏内向;因此走出去交朋友乍看起来挺难。幸运的是,没有什么能阻止你加入自己感兴趣的主题社群,或参加 meetup 学习新技能。
Understanding team strategy
理解团队将如何达成目标,以及你的行为将如何促进或阻碍团队的成功,这对高效工程师至关重要。你应当能够回答以下问题:
Prioritizing appropriately and executing independently
一个能合理排优先级、能独立执行的软件工程师,是每个团队都想留住的人。这样的人理解业务方向,能做出与方向一致的决定。当问题出现时,他们知道如何定位根因,并提出一个同时最小化技术债、提速交付、维持质量、并最终让客户满意的方案。
一个高效的工程师知道什么时候应该主动认领任务和项目,而不需要被直接经理指派。他也清楚什么时候应该借助同事的力量分担负荷,然后有效地与其它团队沟通。
Thinking long term
具备长远思考的能力,是一名高效工程师的重要特质。你需要能看到全局,理解产品的每一个独立组件,是如何契合公司的整体目标的。
能长远思考的工程师,更善于理解新技术未来会如何影响他们的产品。他们也对自己想要在长期发展中营造什么样的团队氛围和文化有更清晰的认识。
一个高效的工程师理解,信任是依靠互相尊重、与团队成员开放沟通,在长期中建立起来的。如果你既想从他人那里获得自主权,又希望在需要创造力和技术能力的项目上保持高效协作,这种行为是必不可少的。
Leaving software projects better than you found them (if time allows)
在时间允许的情况下,你应该始终努力让一个项目在你离开时比找到它时更完善。这包括:让代码变好、确保文档是最新且准确的、清理环境让下一个人更容易接手、随时间改进团队流程和文化,以及通过学习更多与工作相关的语言 / 技术 / 框架来让自己作为开发者不断成长。
你也应该考虑你的工作影响的不只是身边的同事,而是整个组织与社区。例如:如果你正在做的事情会直接影响客户,在开发过程中要格外小心,认真听取他们的反馈。这样,当产品上线时,出现的 bug 或问题应少于平常——因为人们不知道自己还不知道什么!
Being comfortable taking on new challenges
如果组织需求发生变化,一个高效的工程师能够乐于接受新挑战。
适应和学习新事物的能力,是软件工程师这份工作本质的一部分。技术在演进,工作的要求也在变。如果你不能跟组织一起成长,你可能会发现自己越来越吃力——或者更糟,被淘汰。
灵活、迅速地学习,会帮助你在需要时完成适应,在机会出现时(无论是个人职业晋升,还是整个组织层面的机会)做好接手的准备。
Communicating effectively with your team
与你的团队、其他团队、以及客户有效沟通,是至关重要的。这意味着你必须能够把技术信息有效地传递给同事和管理层。如果他们听不懂你在说什么,就可能产生误解,而误解会引发需要修复的 bug 或问题。
与销售、市场等其他干系人有效地沟通,也同样重要。一个软件工程师应当清楚自己的产品做什么、怎么工作、为什么对客户和用户有益——往往以一种经理们没时间弄明白的方式去了解。
与客户沟通时,工程师应当使用简单的语言,避免技术黑话。
Common anti-patterns for software engineering effectiveness
任何优秀的软件工程师都能掌握上述技能,但如果你想达成真正的高效,有几个反模式需要避免。
代码囤积是指你想确保,没有人能够在不理解其工作原理的前提下,接触你的代码库并做改动。如果每个人都把自己的代码放在各自独立的地方,那么团队里的其他人就很难理解这些代码在整体上发生了什么。乍一看这似乎是个好主意,实际上它会导致更慢的开发节奏,让定位和修复 bug 变得更难。
如果多个人在解决类似问题,或者在彼此的工作基础上构建东西,这个问题尤其严重——他们可能最终会对"事情应该怎么工作"形成略有不同的理解,久而久之又会回到混乱之中。
这还意味着项目之间不会有太多共享,每个人可能都想要自己的版本控制系统,而不是依赖一个像 git 或 SVN 那样的共享工具——后者需要正确设置访问权限,以便别人能从对方的仓库拉取 / 推送变更集。
如果有人请你帮一个相关但超出你专长范围的忙,考虑一下这件事是否太费时间,让你无法去做那些本来能更高效的事——比如整理文档、调试现有代码、或为已有功能构建新特性。
一方面,这可能意味着你错过了那些学到新技能、进而带来长期工作保障的机会;但反过来说,这也取决于你所在的环境——这些机会是否经常出现。
Reflections
高效的软件工程师技术扎实、注重细节、能够解决复杂问题。他们具备强大的技术能力、出色的沟通和协作能力,并且能够适应新技术与新挑战。
虽然"什么算高效"会因组织而异,但本文列出的许多特质,是我见过的真正高效的工程师身上所共有的。