更偏好设计技能

2008年1月17日

想象一下招聘场景。有两个候选人,都有几年的经验。在蓝色角落,我们有一个候选人,她在你喜欢的设计风格方面拥有良好的广阔设计技能(在我的情况下,这将是像 DRY、明智地使用模式、TDD、可沟通的代码等,但实际列表并不重要 - 重要的是它是你喜欢的)。然而,她对你们正在使用的特定平台技术一无所知。在红色角落,我们有一个候选人,他对这些问题知之甚少(或不感兴趣),但他非常了解你的平台 - 语言中的边缘情况、可用的库、手指自然地移动到工具上。假设他们其他方面都相同(这永远不会发生,除了像这样的思想实验),并且你的团队没有任何这个候选人可能填补的巨大漏洞。你会更喜欢哪一个?

我的答案很简单,我会选择那个拥有广泛设计技能的人。我一直认为,一个优秀的程序员应该能够相对快速地学习一个新的平台。学习基本的设计美学既更难,也更容易迁移到新的平台。在 Java 中重要的良好设计实践在 .NET 中同样宝贵。不熟悉该平台确实会减慢你的速度(如何在 C# 中再次获取文字类名?),但生成设计良好的代码才是真正起作用的。

广泛的设计技能并不完全可移植。Java 和 .NET 在语言方面基本相同 - 然而,迁移到 Ruby 会改变更多。迁移到一个完全不同的东西,比如函数式语言,是一个更大的转变。无论如何,你不能仅仅盲目地在新的环境中复制所有设计习惯。但如果你了解新世界,很多东西是可以迁移的。

我们在 Thoughtworks 已经看到这个原则证明了自己。在我们早期使用 Java 的时候,我们发现经验丰富的开发人员在 Forte 中学习到的技能为我们提供了在 Java 中工作的优秀直觉。我们很早就从 EJB 主导的思维方式中走了出来,我认为是其他平台的经验指导了我们。我们在 .NET 中看到了更强烈的表现。我们一次又一次地看到,拥有 Java 背景的优秀开发人员比那些拥有更长时间的 .NET 或 Microsoft 背景但缺乏这些技能的开发人员更快地变得更有效率。这种差异在几周内就能看到,而不是几个月(有时甚至几天)。

目前,我们在 Ruby 中最明显地看到了这种转变。今年我们做了很多 Ruby 项目,而且我们经常求助于那些在花括号语言方面拥有丰富经验的人来满足需求。我们再次看到了广泛的设计技能带来的价值。

这并不总是确定的事情。我见过一些在其他平台上有经验的人,他们就是不想学习新的平台。学习的意愿是这里的一个必要组成部分 - 如果那个单一平台专家想学习广泛的设计,而那个广泛的设计师不想学习新的平台,我会选择那个单一平台专家。在团队中拥有一个精通该平台的人也是必不可少的。

我想说,Thoughtworks 的大多数人更喜欢设计技能而不是平台知识。许多客户并不认同这种观点 - 这可能会导致一些困难的务实和道德选择。

如果你想让一个拥有强大设计技能但没有平台背景的人加入你的团队,而客户却坚持要求至少有两年平台经验怎么办?根据你的专业判断,这个广泛的候选人将比任何其他可用的人更有生产力。你需要对你的客户诚实,但另一方面,他是在为你的专业判断付费。如果客户给了你项目交付的责任,这种情况会改变吗?

对我们来说,这些问题更加尖锐,因为其中涉及经济利益。如果我们向一个团队添加一个 ThoughtWorker,那么我们就会为这个人收费。如果客户雇佣了一个平台专家承包商,我们就不会得到这笔收入。对许多人来说,这是这种情况中的一个关键事实,但我相信我们的项目经理足够明智,知道添加错误的人的风险远比一笔可开具的收入更重要。

考虑另一种情况,你对客户坦诚,而客户要求降低那个广泛设计人员的费率,因为她缺乏平台知识,她将在工作中学习。你确信,尽管缺乏经验,她仍然会比竞争的平台专家更有生产力,因为她拥有这些设计技能。你应该接受降低的费率吗?

这是我们以及大多数其他职业的本质,你是在工作中学习的。一个平台专家也必须学习广泛的设计技能,如果他想要编写可维护的代码。这里重要的是要记住,学习设计通常比学习平台更难,而且也不确定。给定一个有动力的广泛设计师,我可以相当确定她会及时学习一个平台。但反过来却没有保证。有些人擅长学习平台的细节,但永远无法弄清楚如何编写清晰的代码。

我在这里谈论的是广泛的设计技能 - 我确实相信这在技术轴上有所不同。但还有其他方面的广阔性。软件项目中的大多数风险都存在于业务人员和程序员之间的沟通中,因此一个能够与用户良好沟通的候选人会为团队带来很多价值。

类似的问题是问题领域的知识。客户通常想要那些已经了解他们业务的人,但当有人迅速获得足够的理解变得有用时,他们会感到惊讶。我一直认为,与他人合作的能力在这里至关重要。通过与领域专家或平台专家合作,一个拥有广泛技能的人可以很快变得有效率。其他领域的知识通常会为项目带来令人惊讶的见解,而且相似之处通常会出现在意想不到的地方。令人惊奇的是,像核心会计模式这样的东西经常出现在表面上看起来不像会计的地方。最终,与他人合作的能力,加上快速学习的能力,才是关键技能。

我并不是在这里贬低深厚的平台知识。在理想的世界里,每个团队成员都应该是优秀的广泛程序员,拥有多年的平台经验,熟悉问题领域,并且至少在之前两次编写过类似的系统。但我们都知道我们的世界离这个理想有多远。你需要在团队中有一些平台知识,如果这是一个差距,我会选择平台专家来填补它。但这不会改变我大多数情况下更喜欢广泛设计技能的默认立场。