大多数技术问题都是人际问题

Source: Hacker News

Background

我曾在一家技术债务极其庞大的公司工作——代码量达数百万行，没有单元测试，使用的框架已经超过十年陈旧。在一个特定项目中，我们需要在 Linux 上运行仅限 Windows 的模块。与其交叉编译，另一团队只是复制粘贴了数十万行代码，把 Windows‑specific 的组件换成了 Linux‑specific 的组件。

对于非技术读者来说，这会导致一个巨大的问题：现在存在两个代码版本，所有功能或 bug 修复都必须同时应用到两个代码库，而这两个代码库会随时间而分歧。当我听说这件事时，年轻且天真的我决定去解决这个局面……

技术债务项目总是很难向管理层推销，因为即使一切顺利，代码也只会大致做它以前做的事。 这看起来并不光鲜，但我忽略了政治因素，低头干活，终于完成了。项目耗时很长，我也因此失去了不少威望。

我意识到自己在用技术方案去解决人的问题。大多数开发者满足于继续做昨天（甚至五年前）做的事。正如 Andrew Harmel‑Law 所指出的，代码往往会反映编写它的人的个性。代码之所以僵化，是因为开发者本身也僵化；不喜欢改变的性格类型很少会设计出便于未来变更的代码。

大多数技术问题其实是人际问题。 技术债务为何会出现？

• 需求在工作开始前没有得到充分澄清。
• 销售人员向客户承诺了不切实际的交付期限。
• 开发者因为舒适感而选择了过时的技术。
• 管理层反应过于被动，在项目进行中途取消了项目。
• 某人的自尊心不允许他看到更好的做事方式。

根本问题在于，承认需要重构也意味着承认公司的软件构建流程已经出现问题，且个人技能已经过时。我的小团队尝试重构一个模块，而其他开发者仍然按他们数十年来的方式写代码。甚至有开发者对我说：“我不想学任何新东西。”我意识到 你永远清理不了技术债务，速度快于它们被创造的速度。 这就像急诊室的分诊：必须先止血，然后才能修复其他损坏。

An Ideal World

这个项目也让我摆脱了工程师对理想世界的幻想——即工程问题可以在真空中解决——远离“政治”，让工作自行说明，一切都不受截止日期约束……说实话，客户也不存在。这样的理想世界很少出现。绝大多数项目都有非技术利益相关者，单纯说“相信我，我们在处理”根本行不通。

我意识到 团队看起来完成了很多工作这一感知，和实际完成很多工作同等重要。 非技术人员并不会直观地理解所需的工作量或技术债务清理的必要性；这必须由工程团队有效传达——无论是在最初的估算还是项目更新中。除非领导层本身有工程背景，否则技术债务工作的价值往往需要量化并展示为业务价值。

Heads Up

也许这些经验正是为更高层职位做准备的教训。依我之见，任何超过高级工程师层级的人都需要懂得跨职能协作，无论他们走技术路线还是管理路线。学校教授的是计算机科学，而不是如何驾驭性格、 ego 和个人盲点。

我曾与一些了不起的工程师共事——他们的技术深度超过我自己，几乎对你提到的任何技术都了如指掌。年轻时，我想成为那种工程师——“工程师的工程师”。但我现在明白那不是我的性格，我太容易分心（ADD）了。

即便他们（相当）强大，这类工程师往往回避人际交往。悲剧在于，他们是极其高产的个人贡献者（IC），但在更大的项目中可能会失利，因为他们只是一个人——单核处理器的速度终究有限。或许同样有价值的是“预警型编码者”——既深谙技术，又能抬头看到项目风险（技术层面及其他），并引导团队规避这些风险的人。