有這么一種觀點：程序員要想提高技術水平，多讀開源代碼、多參與社區討論與開發好了。我以前很贊同，現在發現不是這樣。
panpan和xuhui對我的批評是，多看看技術以外的東西。我的理解是這樣，很多東西它之所以這么做，不是因為技術上是優的，而是因為工期、領導的旨意、需求變更留下的歷史問題等等。這些原因是無法通過閱讀代碼而得知的，我只能看到實現細節，卻不能知道作者的設計意圖。像Qt、 leveldb這樣的項目，名為開源，但是它并沒有采用開放式的開發。只是這個公司將其技術成果共享出來了而已，中間的過程完全不可得知。舉個例子，Nokia和Intel說要合伙做一個叫Meego的操作系統。Intel說好啊，我對Linux熟，我來優化底層系統，Nokia你來搞QT及上層軟件。結果Intel很郁悶的發現，Nokia的Meego項目組有兩套BUG管理系統，一套是對內的，只有Nokia自己的員工可以訪問(intel的不行)，一套是對外的，放在社區里讓任何人都可以去提BUG。然后Intel怒了，你這讓我們怎么合作?Nokia也很委屈，因為對任何一個手機廠商來說，未上市的手機的硬件細節是很重要的商業機密，這些東西很容易通過BUG管理系統中的日志文件和coredump流露出來。所以，大多數軟件廠商終選擇的都是Nokia這樣的做法。
很多時候要想清楚自己的目的，是讓項目盡快完工，還是追求純技術?如果是后者，不如老老實實在學校或者研究所呆著。做項目重要的不是解決一個多么大的技術問題，而是盡可能的把所有技術困難都繞開，然后再解決那些不得不解決的。這時便會引申出一個重要原則：Simple is the best。
讀代碼跟讀小說不一樣。寫小說的人心里一定是有讀者在的。所以每拿起一本古典小說的時候，仿佛穿越了時空在跟一個已經死去的人對話。而代碼不一樣，代碼主要還是給機器讀的，以及給自己讀。舉個例子，如果你對C++的模板推導很擅長，你會因為這門技術太晦澀，有人有可能看不懂，而不用嗎?所以如果想通過代碼猜透作者的設計企圖，不管能不能做到，總之為其花費的代價實在是太高。那么有別的方法嗎? 有啊! 跳到這個公司去，中午跟作者一起吃個飯，隨便套兩句，出來了。
對我自己來說，很有幸能在的互聯網公司工作。如果我想去百度、騰迅、阿里中的任何一家，應該都是有機會的。所以，總有比我的老員工，如果有幸遇到一個比較開明的，跟著這樣的人做項目，會學到很多從開源項目、從書本學不到的東西。
這些，大概是我跟1年前之比的轉變吧。
