關於設計模式、設計原則
有人認爲，熟悉了設計模式、設計原則，就學會了設計。其實，設計模式和設計原則，只是前人根據設計實踐做的總結和提煉，設計，歸根到底是要解決問題的，把具體問題的解決辦法，經過一定的抽象，變成程序員的語言。
我見過一些人，他們知識淵博、見識廣博，甚至理論可以給你闡述得冠冕堂皇，但是到了實際需要解決問題的時候，他們卻拿不出巧妙的、優雅的辦法，這是典型的象牙塔人。
另一方面，也有一些人看不起學習設計模式的人，他們覺得他們已經掌握了軟件設計的奧義，這些對他們來說是毫無意義的詞彙，對此大可以一笑置之。
有時候我們反而被設計模式或設計原則粗暴的掌握束縛了手腳，譬如我遇到這樣一件事情，某位努力的程序員，設計的代碼用遍了組合（例如把User對象 放置到Administrator裏面），我好奇地問，有一些類和對象之間的關係很明顯符合繼承的特徵，爲什麼不願意用它？他說，設計原則告訴我們，要多 用組合，少用繼承。我想，對這些優秀的模式、原則、方法論，如果不能透徹地掌握，不能根據實際場景合適地運用，是不是反而不如對其不瞭解來的好呢？
關於多種計算機語言的學習
有人覺得學習一種語言就可以了，學習那麼多語言沒有必要。事實上，多掌握一門合適的計算機語言不僅僅是多掌握一種謀生的工具，如果一種新的語言能夠很大程度上改變你對編程、對設計的看法，那麼興許它就值得你去學習。
譬如C語言，可以培養嚴謹的思維；譬如動態語言，它可以幫助程序員更好地做面向對象的coding；譬如函數式語言，它在工業生產、運算領域有着不可替代的作用。
當然話說回來，所謂術業有專攻，對於某一門計算機語言（包括該語言所需的運行時環境、其中的編譯或解釋的原理）深入的掌握，是很有必要的。
另外，我們時常看到諸多計算機語言孰優孰劣的爭論，計算機語言歸根到底是一種工具，工具是隨着時代發展升級和變更的，單純的優劣爭論沒有太大意義。
關於英語
中國人爲什麼要學英語，程序員爲什麼要學英語，當我把那些方法名、變量名全部取成拼音，一樣可以，誰下的這個破規定？
遺憾的是，諸多學習材料、論文、技術資料（尤其是一些剛出不久的技術），都是英語的；另一方面，國際標準、程序員交流的通用方式，都是英文的，我想肯定很難想象，那些有名的framework、lib的源碼，如果用拼音來寫變量名會成什麼樣子。
所以，如果你的英語不好（至少讀寫不好），就不要給自己找太藉口，英語是一個掌握其他工具的工具，除非你堅信，中文很快就會在計算機界變成世界第一通用的語言。
關於算法
算法有多重要，這一件事的爭議一直都很大。
軟件歸根到底是用來解決問題的，提到算法就不能不提到數學（這也是爲什麼很多軟件領域的大師都具備相當的數學背景），對於解決問題，這裏可以簡單歸納成兩步：
（1）把實際的問題抽象成簡化的數學模型
（2）用算法去解決這個數學問題
算法，在這裏應該是一個廣義的概念（這裏的算法並不僅僅指大學裏學習的狹義的具體算法），算法是解決上述數學問題的辦法。如果工作中你並未意識到它的存在，那只是說明，你抽象出的數學模型比較簡單，解決這個模型的辦法也很簡單，或者有現成的方式可以模仿，或者有現成的框架幫你完成了，以至於你不去關注它、在乎它。
如果你做的事情是充滿創新意義的，是別人從沒有做過的，這時候算法興許就成了決定你成敗的因素。
在當前中國的環境下，視野廣闊和經歷豐富的人很好找，但是企業要招到具備上述兩點能力來解決問題的人，其實是非常困難的。
關於經驗
唯經驗論者的人有很多，他們認爲，在軟件企業的職位、薪水、甚至決策能力，都取決於經驗，一個5年經驗的工程師，肯定比3年經驗的工程師能找到更好的飯碗：
“我是老員工，我工作5年了，憑什麼工作3年的他薪水比我高那麼多”
實際上，很多因素，包括領域積累（這是業務上的，例如互聯網領域、傳統軟件領域，這和所謂的純技術沒有直接關係）、視野、承受壓力的能力等等往往都 在很大程度上取決於“經驗”的積累，但是，這並不是絕對的。有句話叫做“事業一半是幹出來的，一半是總結出來的”，也確實有一些出色的程序員，他們善於總 結、善於觀察和積累，並且善於不斷地思考，這樣的程序員就是擁有更多優秀的經驗。
另一方面，程序員是要來解決問題的，經驗不能代替解決問題，有的人具備更優秀的解決問題的能力，他爲什麼就不能得到更優厚的薪水？