原文：https://blog.joeschrag.com/2023/11/most-technical-problems-are-really.html
我曾在一家技术债务高筑的公司工作——数百万行代码没有单元测试，基于的框架早已过时十多年。在某个特定项目中，市场需要将一些仅限Windows系统的模块迁移到Linux上，然而另一个团队没有采用交叉编译的方式，而是直接复制粘贴了几十万行代码，仅将Windows专属组件替换为Linux专属组件。
对于非技术背景的读者来说，这会造成一个严重问题：代码从此出现两个版本。因此，所有功能开发和漏洞修复都必须在两个独立的代码库中分别进行，而这两个代码库会随着时间推移逐渐脱节。刚得知此事时，年轻又天真的我立志要解决这个问题……
人的问题
向管理层推广技术债务清理项目向来难度重重，因为即便一切进展顺利，代码最终实现的功能也和之前大致相同。这个项目也不例外，且表面情况并不乐观。我像许多工程师一样“无视办公室政治”，埋头苦干并最终完成了任务。但由于项目延期，我在这个过程中失去了管理层的信任。
我意识到，我本质上是在试图用技术方案解决人的问题。这家公司的大多数开发者满足于日复一日、甚至五年来重复同样的工作……正如安德鲁·哈梅尔-劳（Andrew Harmel-Law）所指出的，代码往往会映射出编写者的性格特质。那些极度厌恶变化的人，在设计代码时往往不会考虑未来的迭代需求。
大多数技术问题本质上都是人的问题。不妨想一想：技术债务为何会存在？因为项目启动前需求未得到充分明确；因为销售人员向客户承诺了不切实际的截止日期；因为开发者为了图舒适而选择过时的技术；因为管理层反应过度，在项目中途将其叫停；因为某些人的自尊心让他们无法接受更优的解决方案。
这个项目的核心问题在于：承认需要重构，就等同于承认公司的软件开发方式存在缺陷，且个人技能严重落后于时代。我的小团队试图修复众多模块中的一个，而其他开发者仍在沿用几十年来的老方法编写代码。有一位开发者直言不讳地告诉我：“我不想学任何新东西。”我意识到，技术债务的清理速度永远赶不上它的产生速度。这就像急诊室的伤员分类救治，必须先止血，再处理其他损伤。
理想世界
这个项目也让我摒弃了工程师的理想化认知——认为可以在真空环境中解决工程问题，只需远离“办公室政治”，让工作成果自己说话；认为存在一个没有截止日期、说实话也没有客户的世界。但这种理想世界几乎不存在。绝大多数项目都有非技术背景的利益相关者，仅仅对他们说“相信我，我们正在推进”是远远不够的。我意识到，让他人感知到团队的高效产出，与实际取得高效产出同等重要。
非技术人员无法凭直觉理解技术工作的难度，也难以认同清理技术债务的必要性。因此，工程师必须在初始评估和项目更新中，通过有效沟通向他们传递这些信息。除非领导层具备工程背景，否则技术债务清理工作的价值需要被量化，并转化为商业价值来呈现。
保持警醒
或许这些经历正是晋升高级职位的必修课。在我看来，任何高于高级工程师职级的人，无论选择技术路线还是管理路线，都必须具备跨职能协作能力。学校教授的是计算机科学知识，却没有教会我们如何应对复杂的人性、自尊心和个人盲点。
我曾与一些才华横溢的工程师共事，他们比我优秀得多——无论你提及何种技术，他们都拥有深厚的专业知识。年轻时，我也想成为那样的工程师——“工程师中的工程师”。但现在我意识到，这与我的性格不符。我太容易分心，无法长时间埋头钻研。：）
尽管这些工程师拥有诸多（显著的）优势，但他们往往回避人际交往。作为独立贡献者（IC），他们的工作效率可能极高，但在推进大型项目时可能会遭遇挫折——因为他们毕竟只是单一个体，就像单核处理器终究有性能上限。与之同样有价值的，是“保持警醒的编码者”——这类人既具备深厚的技术功底，又能适时抬头审视项目风险（无论是技术层面还是其他层面），并引导团队避开这些陷阱。