我是一名黑客。在我還就膝蓋那麼高的時候就開始用一台古老的 Commodore 64 寫代碼了。直到今天，也沒有什麼比戴上耳機，破解東西更讓我著魔的了。所以在我創建我的第一家企業時，我就已經知道了很多有關於編程的事情。是不是謬論，且聽我下面一一道來：
我在很多地方工作過，發現成功之中隱藏著這樣一種普遍現象：早期的代碼看上去像是一群程序猿喝醉之後寫的。這聽上去似乎有悖常理，那是因為你得竭盡全力讓企業成長，所以就沒有時間去追求軟件的完美。從另一方面講，失敗的企業，卻會花很多很多時間來修正其代碼庫。
打個比方：如果你是一個壽司師傅。作為你工作的一部分，你收集了一套絕版的刀具。你花時間花精力來完成收藏，它們提升了你作為一名廚師的競爭力。
但無論你每天用多少時間去打磨你的道具，你就不是一個鐵匠。你的工作依然是做壽司。你雖然擁有了世界上最好的刀具，但如果做不好壽司，那麼你的客戶服務就是差評。你的餐館生意永遠不會成功。
軟件也是同樣的道理。當你運營公司的時候，你的業務目的是滿足客戶。代碼只是一個能達到目的的工具，它本身並不是目的。你可以，也應當關心你的代碼，因為這能有助於提升客戶服務。但是，如果錯將工具當作了目標，那麼注定你將一敗塗地。
經驗教訓：你的客戶並不關心什麼測試覆蓋率、技術堆棧，版本控制系統，也不在乎你使用了什麼算法。你的工作就是解決客戶的問題，越方便越好。
這聽起來似乎違背了傳統的創業須知：快速發布！執行！迭代！執行，不需要創意！快速失敗！
上面這些都是偉大的忠告。但是，“不需要創意”，並不意味著我們能通過卓越的執行矯正一個糟糕的點子。成功就是發現好的問題，再好好地解決這個問題。所以，點子好卻沒有好好實現或者完美實現了一個壞點子，都是不行的，當然前者還有得救。
很多程序員被困實現的死亡漩渦中，花了大量的時間去創建各種功能或者修復 bug，相信再添一個功能就能成功。我告訴你，這是錯覺。你只需要解決了某個重要的問題，否則你這樣不斷為產品添加功能根本是沒有意義的，除非你添加的功能確實能解決需要的。
點子好卻沒有好好實現，總比完美實現了一個壞點子要好。
經驗教訓：如果你添加的功能是用來修復一個失敗的產品，那麼最好先問問自己這能不能真正地解決問題。
我總是想不通為什麼這一錯誤會如此之歷久彌堅。無論程序員是第幾次因為同事的糟糕文檔和溝通習慣而陷入困境，他們因此而得出的結論往往還是——程序員天生不擅長這類事情，也不應該做做這些事情。
大錯特錯啊。
如果你是一個團隊的一部分，那麼提升團隊效率最大的一個障礙就是溝通——這不是誇張，團隊面對的是O(n2)問題。如果代碼是你的主要輸出，那麼你需要改變你對編程的看法：代碼是寫給人看的，然後又剛好能在計算機上運行。
很多時候，我看到程序員花了幾個小時孜孜不倦地寫代碼，但是卻省略了用於更新代碼文檔的十分鐘。這是因為他們覺得：“殺雞焉用宰牛刀，這種事情留給以後的人就行了，我的時間寶貴著呢。”從某種意義上講，他們的想法荒謬至極。
經驗教訓：代碼是寫給人看的。沒文檔就不要寫代碼。
你是不是認為，一旦你寫完這個功能，投入產品，那就大功告成了？錯了。每一個功能都有一個生命周期。你今天寫的代碼，如果成功，那麼將會在你之後的多代程序員中耀武揚威。可能，就為了照料你今天寫的代碼，而不得不成立一個團隊。
好好想一想。如果你的工作就是為了照料別人寫的代碼，你願不願意？
解決問題的關鍵是要有危機意思：寫完第一個版本，並不意味著代碼的完結。務必做好文檔、注釋、整理等工作。
經驗教訓：己所不欲，勿施於人。
大多數的程序員認為利用時間的最佳方式是坐在電腦前，戴上耳機敲代碼。但是，如果你寫的每行代碼都必須維護和支持整個產品的生命周期，那麼算法就又有所不同了。
當你是因為愛好寫代碼的時候，那麼你可以為所欲為，做任何你喜歡做的事情。但是如果你是在一個團隊中生產產品，那麼你的首要義務變成了維護現有的代碼。其他的重要工作為：協調、溝通、規劃和指導。
經驗教訓：程序員的工作是解決問題。指的並不總是寫代碼。
有時候，你可能會想：這事情聽起來像是產品經理的工作，而不是程序員的。但是，如果你拿的是寫代碼的薪水——尤其是在初創企業——那麼把自己當成是產品經理吧。如果你也希望產品能獲得成功，那麼從大局出發是至關重要的。這不僅有利於你的初創企業，對你將來的事業發展也很有好處。
最後，如果各位什麼不同見解，歡迎不吝賜教。
英文原文：Five Things I Knew About Programming Before I Did a Startup