本文共 2544 字,大约阅读时间需要 8 分钟。
图片由SpencerImbrock提供|Unsplash 当然,很多开发人员可能都有些技术底子,也接受过心理测试,那么他们的开发效率究竟有多高呢? 在团队中,评价开发人员的效力及其创建代码的能力不能仅根据其独自工作的年数,因为有的人可能工作了5年,但遇到的开发压力和业绩兴许不及有2年工作经验的人。 资深的后端开发人员也可能跟刚入职的前端开发人员水平相当。 那么,该如何区分高效开发人员和普通开发人员呢? 代码知识会更新,但更新速度往往取决于开发人员的一系列特质,而无关乎其现有的专业素养或技能水平。 广阔的知识域
通过观察开发人员掌握知识的深度和广度,可以判断其潜在效力,这与开发人员主攻的软件开发领域并无太大干系。 知识域,指一个人对某学科领域或话题的了解程度。 习得的知识面越宽、话题范围越广,就越有可能将工作中遇到的问题与已有知识域建立联系并进行比较。 因为软件创建的过程实则为翻译的过程。 若开发人员不仅知道如何编写代码,还有其他经验,则能更好地了解对方的需求,想出解决方案。 开发人员将某一特定情况下的规则和定律以及相应期望编写成某种形式,从而实现机器对其的翻译程序。 开发人员若具有其领域以外的广博的知识域,那就意味着对于多种现象也会有自己的见解。 这会让他们会变得高效,因为在编写代码之前,花在搞清楚问题的来龙去脉上的时间减少了。 跨职能技巧
知识域存在于理论世界,而跨职能技巧则体现在实际操作中。 大家都该了解一下,这是胜任某些工作需具备的完全不同的技能。 人在掌握了跨职能技巧后,通常会成为全才,游走于多个领域,有时候是代码,有时候是别的。 举个例子,一个高效的前端开发人员可能有艺术或设计功底——这也是跨职能的规律所在,解释了这些人为何会成为编码专家。 经验不仅来源于开发人员所编码的内容,更多的是数字界面以外的实际操作经验。 具备这样的素养就意味着拥有本领域以外的实战经验。 这也可以解释为什么新入职的开发人员往往在寻找解决问题的出路时表现出色,因为他们来自另一个领域,或者先前在其他行业工作过。 代码哲学家
代码哲学是一门学科,不过有了可用的应用程序后,便不会有多少人继续深究这些东西。 世上有两类开发者。 第一类人会遵循“能运转就不要再碰了”的思想,第二类人就是永远怀着一颗好奇心,想知道为什么? 到底怎么回事? 尽管有时编码任务的时间有限,但好奇心仍不减。 这种好奇心正是代码哲学家工作时思考方式的主要特征。 虽说代码哲学家经验的深度会因工作的数量和项目的密集度受到影响,但这种思考的技能实则很难培养,只能发自内心。 Philosophy这个词本身来源于希腊语,直译为“爱的智慧(loveof wisdom)”想成为代码哲学家,需要不断地更新个人技能,扩充知识面,掌握更多的知识,而不只局限于编码本身。 如此才能更好地了解所执行的操作。 代码哲学家在确定解决方案前,会探索针对该问题的各种样式、技术、数据、结构、架构以及思考模式。 他们不会一头扎进去,而是会选择退一步,力求看清问题的本质。 给予而非索取
说实话,当今我们学到的大部分知识都源于互联网,依靠他人的帮助解决代码问题。 倘若没有这些人,我们就会长时间受困于某一状况。 给予者会回馈于当初帮助其成长为开发人员的更大的群体。 给予将自己知识提供给他人学习的过程——意思是,给予者身上存在一些对于能力较弱者有价值的东西。 给予不是说非要搞什么大动作——它可以很简单,像在Reddit网站回复一则留言,或公开发表一小篇讲述疑难问题的报告,又或者是在网上转发一些有趣的推文。 给予者也会经常帮助线下的同事——也可能是同一办公室里的新人,或者是一些水平相当的人——从不同角度理解事物。 而许多开发人员偏被动,喜欢“潜水”,只听别人的讨论自己却不分享任何东西到圈子里。 不过即便没有“潜水员”的贡献,讨论圈本身也会延续下去。 给予会让开发者优于同行,因为会与他人共同参与其中,而非仅靠自己和即时代码库。 给予型开发者比索取型更高效,因为具有足够的能力将自己的知识转变为他人所能理解的内容。 假如能做到这一点,那这些人在面对索取者力求证实的话题前就会有自己的理解水准。 总结
高效的开发人员擅长处理手头的工作——但有些时候,在开始编码并与团队成员交流之前很难下此定论。 软件和应用程序开发的范围比许多人想象中要广泛许多,其中会跨越不同的层面——从基础架构到用户的最终体验。 开发人员倾向于结合其他知识来研究特定的层,了解其运转方式。 尽管这样看起来挺不错,但将不同的层级结合起来同时研究就没这么简单了。 灵活的跨职能团队需要的是那些不仅通晓自己领域的知识,也能在其他领域间轻松转换的人。 他们会与没有技术天赋或没有深入了解自己领域的人有着共同语言。 这正是团队所需的人才,他们的效率和效力极高,远超于编码技能所能创造的价值。 这些人起作用、效率高,因为他们是给予者——积极主动,思维明晰。 同时也是代码哲学家,常常拒绝接受公司的现状。 他们会提出质疑,不仅对过去所做的事做出判断,也对未来有所规划。 因为某事之前按照哪种方式处理,并不意味着那就是最高效最有效的方法。 这些人提倡做出改变,是减少技术债务的最佳人选。 他们会为疑难问题找到新的有效解决方案——要知道并非所有开发人员都能做得到或是发自内心想做的。 高效的开发人员就像能够即兴演奏的音乐家一样——听完某段曲子后再用专业的乐器演奏出来。 该特质会使他们看起来与那些只会演奏活页乐谱的音乐家有所不同甚至更具优势。 https://medium.com/better-programming/the-art-of-spotting-highly-effective-developers-in-the-wild-99388fee4b1c