想当程序员，你该知道这5个编程谬论

我是一名黑客。在我还就膝盖那么高的时候就开始用一台古老的Commodore 64写代码了。直到今天，也没有什么比戴上耳机，破解东西更让我着魔的了。所以在我创建我的第一家企业时，我就已经知道了很多有关于编程的事情。是不是谬论，且听我下面一一道来：

1、代码很重要

我在很多地方工作过，发现成功之中隐藏着这样一种普遍现象：早期的代码看上去像是一群程序猿喝醉之后写的。这听上去似乎有悖常理，那是因为你得竭尽全力让企业成长，所以就没有时间去追求软件的完美。从另一方面讲，失败的企业，却会花很多很多时间来修正其代码库。

打个比方：如果你是一个寿司师傅。作为你工作的一部分，你收集了一套绝版的刀具。你花时间花精力来完成收藏，它们提升了你作为一名厨师的竞争力。

但无论你每天用多少时间去打磨你的道具，你就不是一个铁匠。你的工作依然是做寿司。你虽然拥有了世界上最好的刀具，但如果做不好寿司，那么你的客户服务就是差评。你的餐馆生意永远不会成功。

软件也是同样的道理。当你运营公司的时候，你的业务目的是满足客户。代码只是一个能达到目的的工具，它本身并不是目的。你可以，也应当关心你的代码，因为这能有助于提升客户服务。但是，如果错将工具当作了目标，那么注定你将一败涂地。

经验教训：你的客户并不关心什么测试覆盖率、技术堆栈，版本控制系统，也不在乎你使用了什么算法。你的工作就是解决客户的问题，越方便越好。

2、关注实现，而不是点子

这听起来似乎违背了传统的创业须知：快速发布！执行！迭代！执行，不需要创意！快速失败！

上面这些都是伟大的忠告。但是，“不需要创意”，并不意味着我们能通过卓越的执行矫正一个糟糕的点子。成功就是发现好的问题，再好好地解决这个问题。所以，点子好却没有好好实现或者完美实现了一个坏点子，都是不行的，当然前者还有得救。

很多程序员被困实现的死亡漩涡中，花了大量的时间去创建各种功能或者修复bug，相信再添一个功能就能成功。我告诉你，这是错觉。你只需要解决了某个重要的问题，否则你这样不断为产品添加功能根本是没有意义的，除非你添加的功能确实能解决需要的。

点子好却没有好好实现，总比完美实现了一个坏点子要好。

经验教训：如果你添加的功能是用来修复一个失败的产品，那么最好先问问自己这能不能真正地解决问题。

3、代码是写给计算机的

我总是想不通为什么这一错误会如此之历久弥坚。无论程序员是第几次因为同事的糟糕文档和沟通习惯而陷入困境，他们因此而得出的结论往往还是程序员天生不擅长这类事情，也不应该做做这些事情。

大错特错啊。

如果你是一个团队的一部分，那么提升团队效率最大的一个障碍就是沟通这不是夸张，团队面对的是O(n2)问题。如果代码是你的主要输出，那么你需要改变你对编程的看法：代码是写给人看的，然后又刚好能在计算机上运行。

很多时候，我看到程序员花了几个小时孜孜不倦地写代码，但是却省略了用于更新代码文档的十分钟。这是因为他们觉得：“杀鸡焉用宰牛刀，这种事情留给以后的人就行了，我的时间宝贵着呢。”从某种意义上讲，他们的想法荒谬至极。

经验教训：代码是写给人看的。没文档就不要写代码。

4、这是代码编写的最后一步了

你是不是认为，一旦你写完这个功能，投入产品，那就大功告成了？错了。每一个功能都有一个生命周期。你今天写的代码，如果成功，那么将会在你之后的多代程序员中耀武扬威。可能，就为了照料你今天写的代码，而不得不成立一个团队。

好好想一想。如果你的工作就是为了照料别人写的代码，你愿不愿意？

解决问题的关键是要有危机意思：写完第一个版本，并不意味着代码的完结。务必做好文档、注释、整理等工作。

经验教训：己所不欲，勿施于人。

5、程序员的工作就是写代码

大多数的程序员认为利用时间的最佳方式是坐在电脑前，戴上耳机敲代码。但是，如果你写的每行代码都必须维护和支持整个产品的生命周期，那么算法就又有所不同了。

当你是因为爱好写代码的时候，那么你可以为所欲为，做任何你喜欢做的事情。但是如果你是在一个团队中生产产品，那么你的首要义务变成了维护现有的代码。其他的重要工作为：协调、沟通、规划和指导。

经验教训：程序员的工作是解决问题。指的并不总是写代码。

你不仅是程序员，也是产品经理

有时候，你可能会想：这事情听起来像是产品经理的工作，而不是程序员的。但是，如果你拿的是写代码的薪水尤其是在初创企业那么把自己当成是产品经理吧。如果你也希望产品能获得成功，那么从大局出发是至关重要的。这不仅有利于你的初创企业，对你将来的事业发展也很有好处。

最后，如果各位什么不同见解，欢迎不吝赐教。