这是我对团队每个新进员工说的第一件事情。这句话的意思是，我并不关心你是如何快速完成任务的，哪怕代码很差，只要它像救生艇通气门一样管用就行。这句话也是我最喜欢的座右铭之一。
这个说法其实很合理：我们的工作是思考客户提出的问题，然后制定解决方案。思考第一，代码第二，公司请我们的最终目的不是写代码，而是想出解决方案。
话粗理不粗。
付你薪水不是让你来思考的，也不是让你来写代码的，你的目的是交付产品。要是不能交付有效的产品给客户，那么你的知识，技能，态度，以及所有能让人成为高效程序员的特性又有什么意义呢？！
没有客户会说：“嗯，要是能用空格代替tab键表示缩进，那代码将更具可读性。”也没有客户会要求我们使用单向散列存储的密码，事实上他们可能听都没听说过。没有客户会强求我们想出所有可能的架构和平台，然后择优选用。更加没有客户会问及他们的项目使用的是什么代码标准。
客户不在乎代码，也不在乎架构，更加不在乎整个系统是否臃肿不堪。他们想要的就是解决他们的问题。
真正的难点在于权衡以下这两个极端：我们的工作就是写代码，亦或是认为，代码和产品这两个条件永远无法同时满足。
下面让我们认识两位新手程序员——Sam和Ted。ps：如有雷同，纯属巧合。
Sam是一名从刚从当地一所大学毕业的新员工，是个标标准准的学霸。她的面试和FizzBuzz测试表现都非常出色，现在她正式开始她的第一天程序员生涯工作（被聘用了！）。你，作为项目负责人，指派给她第一个任务。因为她才刚开始，所以任务并不难，你（作为一名有经验的开发人员）觉得大概一小时时间就能搞定，不过，你基于保守估计，认为她可能需要用一天的时间。
最终她花了一个星期时间！从第二天开始，每次检查的时候，她都信誓旦旦地说一切进展顺利，代码会写得非常完美。最后终于完成了，果然如她所说的那样：代码完美得像艺术品。但是，请注意，她花了一个星期的时间才完成了这项本应该不超过一天的任务。
现在，来说说Ted。
Ted和Sam同一天被录用。他的面试也很顺利，尽管他完成问题的速度非常快。你也给了Ted一个相对简单的任务：大概需要一天时间。
但是他只花了一小时！在你中午的休息时间，Ted就噌噌噌跑过来交任务了——瞧那骄傲自得沾沾自喜的样子，仿佛在一个劲说“求表扬，求给赞！”但是一看他的代码，就只能呵呵了：很多复制粘贴来的代码片段，乱七八糟的函数命名，组织混乱，雾里看花的解释，等等等等，就像一锅大杂烩一样，你不认识我我也不认识你。
你的团队更属意谁呢，Sam还是Ted？都不是。这两个实际上都不能提供真正的产品？他们一样糟糕：一个思考得太多，另一个则思考得太少。
所以，谨记这一点，付你薪水不仅仅是让你来写代码的，也不是仅仅只需要思考，你还需要开发出能够解决问题的产品。
对此，你的看法呢？欢迎各抒己见。