一個技術從業人員眼中的2014

年輕的同學喜歡按學習曲線來看自己過去的每一年，但是這種方式很快就會步入到瓶頸，學習曲線增長突然會變得緩慢。在2013年聖誕節時，Tim還在每天花上10-30分鐘玩一款叫Clash of Clans的遊戲，並邀請身邊的朋友都加入了部落，當時每天的升級成長也很快。但不知道從哪一天開始，發覺升級越來越慢了，需要2周或者更長時間才能將一些物件升級，所以慢慢的對其失去了成就感、耐心與好奇心。

工程師對於技術的關係也是如此，剛接觸第一門程式語言時候，對每一個細節充滿了好奇心，發現一種新的語法糖也會興奮不已。當使用這些技能之後，慢慢的發現工作中只會重複的使用其中20%左右的領域，就這樣月復一月的過著。當然學習的習慣還繼續保留，工作之外的東西也會去看看其他一些東西，比如花一週學習媒體炒得火熱的Swift語言。但較常見的情況是，大家學的這些新潮技術工作中一般不會立即使用，幾個月之後Swift怎麼寫可能一點也不記得了。幾次類似經歷之後，當再有新的某項技術出來，如果看不到有使用的需要，你已經不打算再學了。畢竟花很大力氣學會某項東西，又註定在幾個月後會忘記，這種做無用功的感覺很不好。因此最終學習曲線會停滯在某個點。

前幾年在新年來臨之際Tim也會去給一些技術媒體投稿，徹夜不眠寫出一篇技術圈巨集大的總結與展望，希望能給從業人員指出一條明路。但是這種憑藉個人視野有感而寫出來的東西，最終指導不了自己也指導不了別人。技術領域太廣太深，即使圖靈獎得主也很難去評論另外一個專業領域未來一年的發展趨勢，能看到的各種預測無非是主流媒體的觀點彙集而已。於是後來就不寫（也不看）這種總結展望了。儘管技術領域內盲從的心理還是非常顯著，很需要這種指南類的東西（比“乾貨”受歡迎多了）。

在2014年日常感悟比較多的，就是對昨天文章技術團隊的標準化與可複用文化所說的技術群體裡面的無序感到有些悲觀。當一個低階問題，第一次解決時，你會感受到成就；第二次解決時，你感受到責任，第三次解決時，你可能更多的感受到無力。當你觀察一個小的團隊時時，這些情況不會明顯；但當你把目光聚焦在一個稍大的團隊，比如50人以上時，這種問題會更容易發現。

有人倡導自組織團隊，包括各級大佬BOSS們也給我們指出這是前進的方向，但是完全具有自組織特徵的團隊不是很容易見到。Tim身邊更多情況是靠各級管理者強有力的執行力去推動。想想如果沒有領導的角色可以自運作起來，還是很有挑戰的一件事情。當然挑戰不包括各種技術大會的那些敏捷教練們。

開源這個詞有些濫用，我個人去評價一個專案時候更多的是看它解決的問題以及帶來的價值。國內業界的問題不是開源不夠，而是能創造價值的軟體太少。單純去討論開源運動我覺得和討論”跑步運動“或者”站立辦公“沒什麼區別，雖然我也嘗試站立辦公，但是我覺得沒必要天天掛在嘴上。

運營開源最重要的是社群（指貢獻你專案程式碼的群體），先是有了社群，然後有了你的開源project。否則你的專案最多會成為一個帶原始碼的一款工具軟體。經常的誤區是一些人覺得將內部的一堆不再維護的程式碼上傳到github上，然後就期望一夜成名，或覺得船到橋頭自然直，這就有點naive了。

雖然大資料很熱，但是我認可大部分engineering方向的工程師不適合做大資料這個觀點。不是說這些人不夠聰明，而是當你已經25歲左右時候，你已經用了3-5年“最好的程式語言”之後，來決定踏入大資料演算法這道門，時機有些晚了。大資料的演算法是稍微和電腦科學的“科學”二字最搭邊的一門學科，這個演算法和CS學的那些快速排序演算法有很大的區別，通常這些半路進入的engineering類的工程師，最終的天花板可能是一個資料統計工程師或者是協同過濾工程師。即便如此，一代又一代工程類的技術人員義無反顧走了進去，經過半年一年狂熱的學習之後，在一些大BOSS不理解的崗位上默默的發揮著作用，並堅信自己已經是邁向金礦的康莊大道上。大部分沒有Critical thinking sense的工程師，習慣在因與果之間用“自然而然”推理並聯系起來，比如“只要我進一步學好大資料演算法，自然而然，就能挖到金礦”。