本文批评了科技公司的两个极端行为：
- 第一个只关心可量化的结果，并将技术债务归咎于工程师；
- 第二种情况是，员工整天花在很少阅读的文档和配置上，而初级工程师则希望使用流行的工具。
虽然两者同样糟糕，但技术人员喜欢抨击前者，而对后者却一无所知。
也许是因为这样做没有动力，而简历驱动的开发 确实能带来更好的回报。
只要公司继续让人们解决与工作无关的晦涩难题，或者招聘经理继续使用自动化系统查找简历中的关键字，一群聪明人就会一直奉行技术最大化主义，为下一个大好机会做准备，从而使底层产品陷入失败。
公司越大、越成熟，第二种类型的特性就越明显。再加上中层管理者对下面的工蜂在做什么一无所知，这就是酿成灾难的完美配方。如果不会导致这些无聊的人梦想成为建筑宇航员，通过引入荒谬的复杂工具来解决想象中的问题，那么花大把钞票来调整衬垫或按钮也许并不是世界上最糟糕的事情。
当公司开始引入一些无用的指标，如 LOCs、PR 计数或功能单数量来量化开发人员的工作效率时，情况就会进一步恶化。这往往会导致不必要的票据产生，并引发恶性的公关循环，开发人员会无休止地争论最佳实践、微优化、无谓的细枝末节以及核心业务逻辑之外的其他一切问题。
如果在业务逻辑上下功夫都得不到回报，那为什么还要把精力放在改善业务逻辑上呢？
显然，在 RPC 的调用路径中引入一个死字队列比编写一个重试装饰器并监控其是否有效更有利可图。
现在，微服务已不再流行，许多公司因采用 Netflix 的工作方式而焦头烂额，尽管它们的收入或人力都没有达到这种水平，但仍不乏文章讨论：
- 采用 SoA 有多么糟糕，而 PostgreSQL 支持的 Django 单体可能就能完成工作。
- 此外，当一个简单的去规范化二级索引就足够了时，GraphQL 是多么糟糕；
- 或者 JavaScript 前端框架的高流失率是如何浪费时间、精力和金钱的。
但是，很少有人提到组织结构和政策是如何迫使人们走这条路的。
必须有一个中间地带，让开发人员可以专注于核心业务逻辑，从而产生最大价值，而不会产生技术债务，使开发过程成为一场噩梦。
我没有答案，也没有在哪家公司找到了完美的平衡。
另外，我不是技术负责人、经理或企业主。所以，如果你是他们中的一员，我很想听听你或你的组织打算如何解决这个问题。
网友讨论：
- 平衡业务需求与技术要求。找到正确的中间立场，让开发人员可以专注于核心业务逻辑，而不会承担太多的技术债务。
- 滥用“技术债务”一词。工程师经常用它作为借口来从事可能无法真正偿还债务的事情。项目经理认为这意味着开发人员只是想玩玩。
- 建立团队之间的信任。如果同行之间相互信任，小的重构和改进将毫无疑问地被接受。与不懂技术工作的项目经理很难建立信任。
- 学习 Pivotal Labs 的流程。他们对 Pivotal Tracker 和类似 Scrum 流程的使用找到了良好的平衡。熟练的 Scrum Master 的持续帮助提高了生产力。但如果没有经验，这种文化很难复制。