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