本文作者列举了软件开发者中两个乱象，一个是只追求可衡量的业务结果，而忽视技术债务，进而导致程序员被苛刻指责；另一种则是过度追求技术的花哨和复杂，而忽视了核心业务逻辑。这种极端情况都不利于企业的长远发展，而后者却很容易被管理层忽略。
在实际的技术开发中，开发者将已存在的有效工具应用到当前面临的业务问题之中，并在业务上进行快速迭代，远比无休止地陷入技术术语的漩涡更为重要，而这一点被普遍低估了。
本文作者曾在两种类型的公司工作过，第一种是只追求可衡量的业务成果，忽视技术债务，并在没人愿意使用他们的代码库时，对工程师提出苛刻的指责；另一方面是过度追求技术的花哨和复杂，让他们的高级工程师整天配置代码检查工具并编写很少有人读的RFC，进而忽视了核心的业务逻辑。这两种极端都不利于企业的长远发展，尤其是后者，危害可能更大，但技术管理层很容易抨击前者，对后者却保持无知的幸福感。
或许这是因为没有足够的激励来解决这个问题，而以履历为导向的开发确实能获得更好的回报。只要公司继续让人们解决与工作无关的晦涩难解的问题，或者招聘经理继续使用自动化系统来搜索简历中的关键词，一群聪明的人将始终追求技术的极致，为下一个重大机会做准备，而将基础产品置于失败的境地。
当公司规模逐渐扩大、业务逐渐成熟时，第二种情况变得越来越常见。中层管理人员对底层工作的理解有限，导致资源浪费在微观优化和复杂工具的引入上，而忽视了核心的业务需求。他们过度依赖代码检查工具和技术方案，却忽视了开发人员应专注于产生最大价值的核心业务逻辑的重要性。
更糟糕的是，一些公司引入了无用的度量标准来衡量开发者的生产力，比如代码行数、Pull Request 数量或功能票数。这种行为导致开发人员只关注表面的指标，而忽视了核心业务逻辑。他们陷入了无休止的讨论最佳实践、微观优化和多余细节的循环，而忘记了核心业务逻辑的重要性。如果开发人员对核心业务逻辑的工作得不到回报，他们为什么还会专注于改进它呢？
当下，微服务已不再流行，许多公司在没有 Netflix 那样的收入或人力资源的情况下，依然采用 Netflix 的工作方式，这也造就了网络上有大量的文章来说明当使用 PostgreSQL 支持的 Django 单体应用可能已经足够时，采用面向服务架构的坏处。还有一些文章批评GraphQL，认为一个简单的去规范化的二级索引已经足够，或者 JavaScript 前端框架的高流失率浪费了时间、精力和金钱。然而，很少有文章提到组织结构和政策如何迫使人们采取这种方式。
我们需要找到技术与业务的平衡点。这并不是一件容易的事情，需要技术负责人、经理和业务所有者的共同努力。只有通过专注于核心业务逻辑，并避免技术债务的积累，我们才能够实现最大的业务价值。
然而，目前还没有一个完美的解决方案。我个人也没有在这样的公司工作过，因此无法给出确切答案。但我希望借此机会，邀请那些具有技术负责人、经理或业务所有者身份的人，与我们分享他们或他们的组织计划如何解决这个问题。只有通过共享经验和智慧，我们才能够找到更好的平衡点，实现技术和业务的和谐发展。
在当今科技驱动的世界中，我们需要意识到技术只是达到目标的手段，而不是目标本身。通过关注核心业务逻辑，我们可以避免陷入技术的极端主义，拥抱实际的业务需求，实现持续的创新和成功。
希望这篇报道能够引起广大程序员群体的关注，激发有关技术与业务平衡的讨论与思考。让我们共同努力，摆脱技术陷阱，迈向业务的成功之路！
