拿工资不仅仅是让你写代码的

我并不关心你是如何快速完成任务的,哪怕代码很差,只要它像救生艇通气门一样管用就行。这句话也是我最喜欢的座右铭之一。

这个说法其实很合理:我们的工作是思考客户提出的问题,然后制定解决方案。思考第一,代码第二,公司请我们的最终目的不是写代码,而是想出解决方案。

话粗理不粗。

付你薪水不是让你来思考的,也不是让你来写代码的,你的目的是交付产品。如果不能交付有效的产品给客户,那么你的知识,技能,态度,以及所有能让人成为高效程序员的特性又有什么意义呢?!

没有客户会说:“嗯,如果能用空格代替 tab 键表示缩进,那代码将更具可读性。”也没有客户会要求我们使用单向散列存储的密码,事实上他们可能听都没听说过。没有客户会强求我们想出所有可能的架构和平台,然后择优选用。更加没有客户会问及他们的项目使用的是什么代码标准。

客户不在乎代码,也不在乎架构,更加不在乎整个系统是否臃肿不堪。他们想要的就是解决他们的问题。

真正的难点在于权衡以下这两个极端:我们的工作就是写代码,亦或是认为,代码和产品这两个条件永远无法同时满足。

Sam 是一名从刚从当地一所大学毕业的新员工,是个标标准准的学霸。她的面试和 FizzBuzz 测试表现都非常出色,现在她正式开始她的第一天程序员生涯工作(被聘用了!)。你,作为项目负责人,指派给她第一个任务。因为她才刚开始,所以任务并不难,你(作为一名有经验的开发人员)觉得大概一小时时间就能搞定,不过,你基于保守估计,认为她可能需要用一天的时间。

最终她花了一个星期时间!从第二天开始,每次检查的时候,她都信誓旦旦地说一切进展顺利,代码会写得非常完美。最后终于完成了,果然如她所说的那样:代码完美得像艺术品。但是,请注意,她花了一个星期的时间才完成了这项本应该不超过一天的任务。

现在,来说说 Ted。

Ted 和 Sam 同一天被录用。他的面试也很顺利,尽管他完成问题的速度非常快。你也给了 Ted 一个相对简单的任务:大概需要一天时间。

但是他只花了一小时!在你中午的休息时间,Ted 就噌噌噌跑过来交任务了——瞧那骄傲自得沾沾自喜的样子,仿佛在一个劲说“求表扬,求给赞!”但是一看他的代码,就只能呵呵了:很多复制粘贴来的代码片段,乱七八糟的函数命名,组织混乱,雾里看花的解释,等等等等,就像一锅大杂烩一样,你不认识我我也不认识你。

你的团队更属意谁呢,Sam 还是 Ted?都不是。这两个实际上都不能提供真正的产品?他们一样糟糕:一个思考得太多,另一个则思考得太少。

所以,谨记这一点,付你薪水不仅仅是让你来写代码的,也不是仅仅只需要思考,你还需要开发出能够解决问题的产品。

加载余下内容▼

相关文章:

;