當一個低級問題，第一次解決時，你會感受到成就；第二次解決時，你感受到責任，第三次解決時，你可能更多的感受到無力（轉）

　年輕的同學喜歡按學習曲線來看自己過去的每一年，但是這種方式很快就會步入到瓶頸，學習曲線增長突然會變得緩慢。在 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 的工程師，習慣在因與果之間用“自然而然”推理并聯系起來，比如“隻要我進一步學好大資料算法，自然而然，就能挖到金礦”。

　　2013 年元旦時候也寫了一篇談分享、創新與開源，和目前想法也有些明顯的差別。