1. 代碼很重要

我在很多地方工作過，發現成功之中隱藏著這樣一種普遍現象：早期的代碼看上去像是一群程序猿喝醉之后寫的。這聽上去似乎有悖常理，那是因為你得竭盡全力讓企業成長，所以就沒有時間去追求軟件的完美。從另一方面講，失敗的企業，卻會花很多很多時間來修正其代碼庫。

打個比方：如果你是一個壽司師傅。作為你工作的一部分，你收集了一套絕版的刀具。你花時間花精力來完成收藏，它們提升了你作為一名廚師的競爭力。

但無論你每天用多少時間去打磨你的道具，你就不是一個鐵匠。你的工作依然是做壽司。你雖然擁有了世界上最好的刀具，但如果做不好壽司，那么你的客戶服務就是差評。你的餐館生意永遠不會成功。

軟件也是同樣的道理。當你運營公司的時候，你的業務目的是滿足客戶。代碼只是一個能達到目的的工具，它本身并不是目的。你可以，也應當關心你的代碼，因為這能有助于提升客戶服務。但是，如果錯將工具當作了目標，那么注定你將一敗涂地。

經驗教訓：你的客戶并不關心什么測試覆蓋率、技術堆棧，版本控制系統，也不在乎你使用了什么算法。你的工作就是解決客戶的問題，越方便越好。

2. …關注實現，而不是點子。

這聽起來似乎違背了傳統的創業須知：快速發布！執行！迭代！執行，不需要創意！快速失敗！

上面這些都是偉大的忠告。但是，“不需要創意”，并不意味著我們能通過卓越的執行矯正一個糟糕的點子。成功就是發現好的問題，再好好地解決這個問題。所以，點子好卻沒有好好實現或者完美實現了一個壞點子，都是不行的，當然前者還有得救。

很多程序員被困實現的死亡漩渦中，花了大量的時間去創建各種功能或者修復 bug，相信再添一個功能就能成功。我告訴你，這是錯覺。你只需要解決了某個重要的問題，否則你這樣不斷為產品添加功能根本是沒有意義的，除非你添加的功能確實能解決需要的。

點子好卻沒有好好實現，總比完美實現了一個壞點子要好。

經驗教訓：如果你添加的功能是用來修復一個失敗的產品，那么最好先問問自己這能不能真正地解決問題。

3. ……代碼是寫給計算機的

我總是想不通為什么這一錯誤會如此之歷久彌堅。無論程序員是第幾次因為同事的糟糕文檔和溝通習慣而陷入困境，他們因此而得出的結論往往還是——程序員天生不擅長這類事情，也不應該做做這些事情。

大錯特錯啊。

如果你是一個團隊的一部分，那么提升團隊效率最大的一個障礙就是溝通——這不是夸張，團隊面對的是O(n²)問題。如果代碼是你的主要輸出，那么你需要改變你對編程的看法：代碼是寫給人看的，然后又剛好能在計算機上運行。

很多時候，我看到程序員花了幾個小時孜孜不倦地寫代碼，但是卻省略了用于更新代碼文檔的十分鐘。這是因為他們覺得：“殺雞焉用宰牛刀，這種事情留給以后的人就行了，我的時間寶貴著呢。”從某種意義上講，他們的想法荒謬至極。

經驗教訓：代碼是寫給人看的。沒文檔就不要寫代碼。

4. …這是代碼編寫的最后一步了。

你是不是認為，一旦你寫完這個功能，投入產品，那就大功告成了？錯了。每一個功能都有一個生命周期。你今天寫的代碼，如果成功，那么將會在你之后的多代程序員中耀武揚威。可能，就為了照料你今天寫的代碼，而不得不成立一個團隊。

好好想一想。如果你的工作就是為了照料別人寫的代碼，你愿不愿意？

解決問題的關鍵是要有危機意思：寫完第一個版本，并不意味著代碼的完結。務必做好文檔、注釋、整理等工作。

經驗教訓：己所不欲，勿施于人。

5. …程序員的工作就是寫代碼

大多數的程序員認為利用時間的最佳方式是坐在電腦前，戴上耳機敲代碼。但是，如果你寫的每行代碼都必須維護和支持整個產品的生命周期，那么算法就又有所不同了。

當你是因為愛好寫代碼的時候，那么你可以為所欲為，做任何你喜歡做的事情。但是如果你是在一個團隊中生產產品，那么你的首要義務變成了維護現有的代碼。其他的重要工作為：協調、溝通、規劃和指導。

經驗教訓：程序員的工作是解決問題。指的并不總是寫代碼。

你不僅是程序員，也是產品經理。

有時候，你可能會想：這事情聽起來像是產品經理的工作，而不是程序員的。但是，如果你拿的是寫代碼的薪水——尤其是在初創企業——那么把自己當成是 產品經理吧。如果你也希望產品能獲得成功，那么從大局出發是至關重要的。這不僅有利于你的初創企業，對你將來的事業發展也很有好處。

最后，如果各位什么不同見解，歡迎不吝賜教。

英文原文：

中文翻譯：