計算機科學有兩類根本問題。一類是理論：算法，數據結構，復雜度，機器學習，模式識別，等等等。一類是系統：操作系統，網絡系統，分布式系統，存儲系統，游戲引擎，等等等等。

理論走的是深度，是在追問在給定的計算能力約束下如何把一個問題解決得更快更好。而系統走的是廣度，是在追問對于一個現實的需求如何在眾多的技術中設計出最多快好省的技術組合。

搞ACM的人，只練第一類。像你這樣的更偏向于第二類。其實挺難得的，但很可惜的是第二類能力沒有簡單高效的測量考察方法，不像算法和數據結構有ACM競賽，所以很多系統的苗子都因為缺少激勵和正確引導慢慢就消隱了。

所以比爾蓋茨才會說，看到現在學編程的人經常都把編程看作解各種腦筋急轉彎的問題，他覺得很遺憾。

做系統，確實不提倡“重復發明輪子”。但注意，是不提倡“重復發明”，不是不提倡“重新制造”。恰恰相反的，我以為，系統的編程能力正體現在“重新制造”的能力。

能把已有的部件接起來，這很好。但當你恰好缺一種關鍵的膠水的時候，你能寫出來嗎？當一個已有的部件不完全符合你的需求的時候，你能改進它嗎？如果你用的部件中有bug，你能把它修好嗎？在網上繁多的類似功能的部件中，誰好誰壞？為什么？差別本質嗎？一個開源代碼庫，你能把它從一個語言翻譯到另一個語言嗎？從一個平臺移植到另一個平臺嗎？能準確估計自己翻譯和移植的過程需要多少時間嗎？能準確估計翻譯和移植之后性能是會有提升還是會有所下降嗎？

系統編程能力體現在把已有的代碼拿來并變成更好的代碼，體現在把沒用的代碼拿來并變成有用的代碼，體現在把一個做好的輪子拿來能畫出來輪子的設計藍圖，并用道理解釋出設計藍圖中哪些地方是關鍵的，哪些地方是次要的，哪些地方是不容觸碰的，哪些地方是還可以改進的。

如果你一點不懂理論，還是應該學點的。對于系統性能的設計上，算法和數據結構就像在自己手頭的錢一樣，它們不是萬能的，但不懂是萬萬不行的。

怎么提高系統編程能力呢？土辦法：多造輪子。就像學畫畫要畫雞蛋一樣，不是這世界上沒有人會畫雞蛋，但畫雞蛋能馴服手指，感受陰影線條和筆觸。所以，自己多寫點東西吧。寫個編譯器？渲染器？操作系統？web服務器？web瀏覽器？部件都一個個換成自己手寫的，然后和已有的現成部件比一比，看看誰的性能好，誰的易用性好？好在哪兒？差在哪兒？為什么？

更聰明一點的辦法：多拆輪子。多研究別人的代碼是怎么寫的。然而這個實踐起來經常很難。原因：大部分工業上用的輪子可能設計上的思想和技術是好的，都設計和制造過程都很爛，里面亂成一團，讓人乍一看毫無頭緒，導致其對新手來說非常難拆。這種狀況其實非常糟糕。所以，此辦法一般只對比較簡單的輪子好使，對于復雜的輪子，請量力而行。

輪子不好拆，其實是一個非常嚴重的問題。重復發明輪子固然是時間的浪費，但當輪子復雜而又不好拆的時候，尤其是原來造輪子的人已經不在場的時候，重新發明和建造輪子往往會成為無奈之下最好的選擇。這是為什么工業界在明知道重復發明/制造輪子非常不好的情況下還在不斷重復發明/制造輪子的根本原因。

程序本質是邏輯演繹的形式化表達，記載的是人類對這個世界的數字化理解。不能拆的輪子就像那一篇篇丟了曲譜的宋詞一樣，能讀，卻不能唱。

鄙人不才，正在自己研究怎么設計建造一種既好用又好拆的輪子。您沒那么幸運，恐怕是等不到鄙人的技術做出來并發揚光大了。在那之前，多造輪子，多拆好拆的小輪子，應該是提高編程能力最好的辦法了。

本答案來自-