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