这是我对团队中的每个新员工说的第一句话。这意味着我不在乎你多快完成事情，即使代码很糟糕，只要它能像救生艇通风口一样工作。这句话也是我最喜欢的座右铭之一。这句话其实很有道理：我们的工作就是思考客户提出的问题，然后制定解决方案。思考***，代码其次，公司要求我们的最终目的不是写代码，而是想出一个解决方案。言语并不粗鲁。你不是因为思考或编写代码而获得报酬，而是因为交付而获得报酬。如果您不能向客户交付有效的产品，那么您的知识、技能、态度以及使某人成为有效程序员的所有属性又有什么意义呢？！没有客户会说，“好吧，如果我们可以使用空格而不是制表符进行缩进，代码将更具可读性。”没有客户会要求我们将密码存储在单向哈希中。事实上，他们可能不会听。从来没有听说过。没有客户会强迫我们想出所有可能的架构和平台，然后选择最好的使用。而且没有客户会问他们的项目使用什么编码标准。客户不关心代码，不关心架构，也不关心整个系统是否臃肿。他们想要的只是解决他们问题的方法。真正的困难在于平衡两个极端：我们的工作是编写代码，或者相信代码和产品这两个条件永远不能同时满足。让我们认识一下两个新手程序员-Sam和Ted。ps：如有雷同，纯属巧合。山姆是一名刚从当地大学毕业的新员工，是一名标准的学生。她在面试和FizzBu??zz测试中表现出色，现在她正式开始第一天的程序员工作（她被录用了！）。你，作为项目负责人，给她分配了第一个任务。由于她刚刚开始，任务并不太难，你（作为一个有经验的开发人员）认为它可以在大约一个小时内完成，但你比较保守，认为她可能需要一天时间。结果花了她一个星期！从第二天开始，每次检查，她都发誓一切顺利，代码一定会写得完美无缺。***终于完成了，果然如她所说：代码***就像一件艺术品。但是请注意，她花了一周的时间来完成一项本应花费不超过一天的任务。现在，让我们谈谈泰德。Ted和Sam在同一天被录用。他的面试也很顺利，尽管他很快就回答了问题。你还给了泰德一个相对简单的任务：大约需要一天的时间。但他只用了一个小时！中午休息的时候，泰德跑过来交任务——看那得意洋洋的样子，好像一直在说“请表扬，请表扬！”但是看他的代码，就没事了：一堆复制粘贴的代码片段，乱七八糟的函数命名，乱七八糟的组织，含糊不清的解释等等，就像一锅大杂烩，你不认识我我也不认识知道你。你的团队更喜欢谁，Sam还是Ted？两者都不。这些都没有真正交付真正的产品？他们同样糟糕：一个想太多，另一个想得太少。因此，考虑到这一点，您不会因为编写代码而获得报酬，或者只是思考，您获得报酬是为了构建解决问题的产品。你对此有何看法？欢迎发表您的看法。
