技術本身並不是最重要的，關鍵是你能否用它來實現你的想法。
組織能力比演算法技巧更重要
我看過很多關於大公司技術面試的部落格文章，這讓我覺得自己很幸運，因為我不是在找工作。那些面試要求你當場寫出一些複雜的資料結構，比如堆和樹的變種，或者解決一些有嚴格限制的難題。有些數學問題，如果你不能巧妙地分析和重新表述，可能需要一百億年才能算出來。我的第一反應是：哇，他們是怎麼招到人的？
我的第二個反應是：其實大部分程式設計工作根本不需要這種高深的演算法技巧。
說到寫程式碼，最重要的技能其實是如何讓一堆功能不至於因為太複雜而崩潰。我做過很多專案，比如大型電信系統、遊戲機遊戲、部落格軟體，還有一些個人小工具。在這些專案中，很少會遇到那種特別複雜的資料結構或演算法問題。但總是有很多狀態需要跟蹤，很多值需要重新排列，還有很多特殊情況要處理。你得仔細研究系統的各個部分是怎麼相互作用的。
總的來說，寫程式碼更像是一種組織工作。你要不斷重構程式碼，簡化它，想辦法去掉那些不必要的操作。
這也是為什麼有很多人“偶然”成為了程式設計師。你不會看到有人在業餘時間隨便就變成了神經外科醫生——因為那需要專門且密集的訓練。但很多人透過自學掌握了足夠的程式設計技能，能夠自己做出一些東西。當年我在一臺8位家用電腦上學習程式設計時，我甚至不知道“演算法”是什麼。我也不知道怎麼對資料進行排序，不過幸運的是，我做的小遊戲不需要這些知識。我寫的程式碼主要是關於計時器、計數器和狀態管理的。我更像是一個組織者，而不是什麼天才。
幾年前，我開發了一個小工具，用來把圖片組合成矩形紋理。這個程式不大，大概只有1500行程式碼，用的是Erlang和C語言。其中有一個20行的小片段是用來做矩形打包的，雖然寫起來不難，但我懷疑如果讓我在面試中寫出來，我可能做不到。其餘的程式碼主要是用來載入檔案、生成輸出、處理圖片屬性（比如原點），以及處理程式不同部分之間的資料流。每當我需要新功能、更好的錯誤處理或者改進使用者體驗時，我都會去調整這些程式碼。
這其實代表了大多數軟體開發的情況。
寫程式碼更多是關於如何組織和管理，而不是搞什麼高深的演算法魔法。
組織能力
簡單來說，就是把事情安排得井井有條的能力。在程式設計中，組織能力指的是你如何設計和管理程式碼，讓它清晰、易讀、易維護，而不是一團亂麻。具體來說，它包括以下幾個方面：
- 程式碼結構清晰：把程式碼分成合理的模組或函式，每個部分只負責一件事，避免把所有功能都堆在一起。
- 狀態管理：跟蹤和管理程式中的各種狀態（比如變數、資料流），確保它們不會混亂或出錯。
- 處理複雜性：當程式功能越來越多時，如何讓程式碼不至於變得太複雜，避免“牽一髮而動全身”。
- 重構與簡化：不斷最佳化程式碼，去掉重複的部分，簡化邏輯，讓它更容易理解和修改。
- 協調系統各部分：確保程式的不同部分能夠很好地協同工作，資料能正確流動，功能之間不會互相干擾。
舉個例子：假設你寫了一個小遊戲，裡面有計時器、分數計算、角色移動等功能。組織能力強的程式設計師會把這些功能分開寫，比如一個函式專門處理計時器，另一個函式處理分數計算，然後再把它們合理地組合在一起。這樣，當你需要修改某個功能時，不會影響到其他部分。
組織能力不僅僅是分而治之，它還包括如何設計系統結構、管理程式碼、協調模組、處理複雜性等。分而治之是組織能力中的一種工具或方法，但組織能力更注重整體性和可持續性。
例子：如果你在開發一個電商網站，組織能力會讓你：
- 把系統拆分成使用者管理、商品管理、訂單管理等多個模組（分而治之、領域劃分、上下文辨識）。
- 設計清晰的介面，讓這些模組能互相通訊。
- 管理程式碼的複雜度，確保每個模組內部邏輯清晰。
- 處理模組之間的依賴關係，避免混亂。
- 不斷最佳化和重構程式碼，讓系統更容易維護和擴充套件。
組織能力=架構能力+分而治之