各位朋友，我担当程序员已经有5年有余，虽然这并不值得有什么夸耀，你们中许多人随便挑出来都比我多出几倍的工作经验。

但是我此时开始自视为一名高级开发人员。

机缘巧合之下，我应聘上了一家初创公司的首席技术官（CTO）。在新职位上工作一段时间后，我意识到自己距离高级开发人员的标准还有一段差距。这并非因为我编程技术不佳，而是因为我回想起过去工作中常犯的四大错误。那么都有哪些错误呢？我们来分别看一下。

“用户总是愚蠢的”

后来，我意识到错了，他们绝非愚蠢。

我们总结有以下原因：

• 用户使用应用的方式常常出人意料，甚至有些古怪；

• 用户经常会提出一些看似愚蠢的问题；

• 有时用户提出的要求看起来毫无意义；

• 用户有时甚至无法理解一些非常基础的功能。

毕竟，用户并非IT专家。医生不会期望病人能够理解低密度脂蛋白和高密度脂蛋白之间的区别。那么，我们又怎能期望用户了解他们应该使用哪种浏览器呢？尽管对你我而言这个问题显而易见，但对于我母亲来说，谷歌就是互联网的代名词，她说自己没有使用任何浏览器，因为她使用的就是谷歌。

有时，为了满足用户的需求，我不得不重写部分框架，仅仅是为了改变其默认行为。有时，我不得不支持一些原本不打算支持的浏览器（例如Safari）。虽然现在看来这种想法很愚蠢，但当时的我确实认为这是客户的错，是他们的要求迫使我不得不在代码中做出妥协。

代码即艺术，必须追求完美

整洁的代码、严密的单元测试、完善的文档，这些无疑都至关重要。作为一名程序员，我总是要求自己使用现代编程模式编写清晰的代码，并且我会定期检查所有依赖项是否为最新的。

因为，我渴望成为一名卓越的程序员。

每当我的产品经理要求我暂停单元测试，加快开发新功能的速度时，我就会感到愤怒。为什么他不能理解单元测试的重要性呢？当时，我们没有其他自动化测试，单元测试是确保产品稳定性和避免回归问题的唯一保障。

在我看来，产品经理提出这种要求是因为他缺乏远见。更糟糕的是，他还暗示我停止编写技术文档，将代码转换为更简单的架构（尽管此时项目才刚刚开始）。

我承认，压缩这些工作确实可以加快开发速度，但未来我们肯定会因此遇到许多问题。我们将不得不花费大量时间修复回归错误，而且随着项目的推进，新的架构也会变得过于简单。此外，如果没有完善的文档，新加入的程序员又如何能快速融入项目里呢？

为此，我们花费了数小时反复地讨论，并分析了未来可能带来的损失。

然而几个月后，那个项目因预算严重超支而宣告失败。

多年后，我不得不承认，我们的团队犯了一个巨大的错误。我们只顾着考虑未来，却忽略了眼前。我们完全忽视了当时的情况：当时预算有限，需要在短时间内迅速构建最小可行产品。

编写出可以向他人展示且令人自豪的代码固然很好，但能够顺利完成项目不是更好吗？毕竟，编程有时并非艺术。

只选择自己熟悉的技术堆栈

我在前一家公司工作时，每次创建新项目，我们总是使用相同的技术堆栈：Symfony和Angular。Symfony是最好的后端框架吗？并不是。Angular是创建现代前端的唯一方法吗？也不是。我们总是选择这套技术，因为我们对其他技术不够了解。我们一直在自己的舒适区里打转。但在新项目中选择众所周知的技术有错吗？这要视情况而定。

在许多的情况下，下一个项目与之前的项目总会有一些相似之处。由于你已经有了可靠的解决方案，因此花大量时间学习新技术似乎没有意义。但有时，这种决定可能并不正确。

我记得有一个项目，其核心需求是一个运行良好的WebSocket。我们选择了哪种技术来构建后端呢？当然是Symfony。也许现在使用PHP创建WebSocket很容易，但在当时却是一场噩梦。我们投入了巨大的努力才让系统运行起来。当时我们明知使用PHP创建WebSocket会耗费大量时间和金钱，但我们还是放弃了使用Node.js的想法。为什么？我自己也不清楚。我们可以利用Node.js构建速度是原API十倍的API，但仅仅因为我们的技术栈中没有Node.js。

我很高兴现在的团队成员都非常开放。就在上周，我们决定使用一种全新的技术来构建我们系统的一部分。我相信这个决定将为我们节省大量时间，尽管需要从头开始学习新技术。

产品经理太糟糕了，我来会更好

当我还是程序员时，说实话，我和产品经理的关系并不咋融洽。每当他告诉我计划范围有所变动时，我都会感到愤怒：

“为什么你不能做好自己的工作，事先定义好范围呢？事先决定功能需求有那么难吗？”

当时的我太天真了，把事情想得太简单。

现在我终于明白，详细规划项目的每一个细节是极其困难的。首先，你必须考虑到技术和预算的限制；其次，你必须设身处地为产品的用户着想，不能忘记业务和市场的需求。你无法在项目开始时就掌握所有需求；有时，业务环境会发生变化；有时，你必须先构建一部分产品，然后再逐步完善。

此外，产品经理也可能会犯错。程序员会编写出bug，产品经理也会犯错。现在想来，这都是显而易见的。如果当时我能意识到这一点，那么我可能会成为一名更好的程序员。我不应该固执己见，只为了证明产品经理错了，而应该集中精力寻找解决方案。

有时，我甚至忘记了自己和产品经理有着共同的目标，即打造出色的产品。

现在回想起来，我不禁感到羞愧。产品经理掌握的关于预算、业务状况、客户需求、截止日期和优先级的信息比我多，这也就是为什么我不理解他们为何做出某些决定的原因。

结语

对于一些伙伴来说，以上四点可能是显而易见的。如果你所在的团队强大、组织良好，拥有出色的领导，并且你始终记得用户体验（UX）的基本原则，那么我真心为你感到高兴。

我相信你会成为一名比我更出色的程序员。因为“一名优秀的程序员”不仅仅是掌握技术知识。

了解你能为公司带来哪些价值，以及如何实现这些价值，至关重要。

现在，我们对高级开发人员的理解如下：

高级开发人员不仅仅是技术方面的专家。在必要时，他们会走出自己的舒适区，帮助公司打造出色的产品。

此外，他们是那些更注重解决方案而非问题本身的人。

祝您编码愉快！如果本文有用，请您点赞、在看与转发！

作者：田野

参考：

https://medium.com/better-programming/4-mistakes-i-made-as-a-programmer-but-i-had-to-become-a-cto-to-see-them-19a41ba70411