眼前的工作即將告一段落了，想著有必要對這段經歷總結一下。寫這些并不是為了分享什么有價值的經驗，因為這兩年最大的體會就是：二手經驗不會讓人有多大成長，唯有腳踏實地的去經歷才能變得智慧。所以反思的目的是為了整理并記錄下自己的一些思考，希望自己以后別在同一個地方掉坑。
關于管理其實從上家公司起，工作內容就開始接觸一些管理的事宜了，但屬于被強制委托不得不管；換工作后，正好有這么個機會，就想著去爭取嘗試一下，雖然只有三兩個人，但也算邁出這一步了。這么做并不是因為年齡到了，或是工作年限到了。只是因為隨著能力和視野提升，總是想著去做一些更有挑戰的事情；而有挑戰的事情自然有其自身的復雜性。其中包含著大量繁雜瑣碎的工作，很多都是自己在過去反復做過很多次的內容，不想自己動手，就只能尋找他人來協助。
我覺得一個優秀的 Leader，應該是自帶氣場的，并且有清晰的目標和做事原則。能夠匯聚諸多追隨者。但這種 Leader 在職場中其實很難遇到，至少我遇到的大多數都不是，只不過是一個個高級打工人而已；但于我而言，還是能從他們身上學到很多東西，反面教材也可以是好教材。對于20人以下小團隊，總結下來主要有以下這幾點：
團隊目標（畫餅）是很重要的，而且必須是確定而且堅定的，不能每天想一出是一出，自己都沒頭緒。如果所在的環境就很亂，比如自己有個很糟糕的領導，或外部環境惡劣，無法制定出持久的目標，那最好趁早走人。搞清團隊成員的個人意愿，為其找一個合適的定位和方向。講清楚對他的期望。這點和目標一樣，是不可以隨意變化的。否則下屬沒辦法做事。如果實在找不到合適的定位，說明這個人并不適合當前的團隊。用人不疑。如果某一個方向自己懂得不多，確定好方向上的目標，剩下的就是信任。如果就是不放心，就讓2個人以競爭的關系做同一個方向。確定內外部協作流程，流程和定位是相呼應的。要對所有具體工作內容有很清晰的理解，否則協作過程中的邊界問題，容易出現摩擦。別忘了把自身也納入到流程之中。明確做事標準，表明自己的態度和喜惡。優秀的表現要得到看得見的表揚；差勁的表現不必懲罰，只需在團隊內公開提出即可，誅心已經是很大的懲罰了。Leader的喜惡很影響下屬做事的側重點。如果有下屬單純只是主觀（或價值觀）上反對團隊做事的標準和流程，最好把他踢出團隊，強扭的瓜不甜。這種人容易攪亂團隊。定期的團建是非常重要的。團建可以消解很多團隊內部矛盾。跟合作團隊一起團建，也更容易促進合作。再就是可以和大家打成一片，比較方便做事。重要的信息往往都是在外面閑聊時獲得的。把控整個團隊的對外輸出內容，無論是做產品，還是做服務。都要對交付內容有很好的把控。要清楚自己是團隊的軸心，以身作則。自身的一舉一動可能都會被下屬看到，并影響到團隊。下屬很多時候不會跟領導說實話。
有些瑣碎，進一步抽象總結下，自己這兩年主要有 2 個大錯誤。
一是沒有清晰恒定的目標，沒有很具體地想清楚到底做成什么，導致付出了很多無意義努力。到最后大家都覺得我所負責的方向有點亂，亂七八糟啥都有，還啥都缺，不成體系。但這里很重要的一個原因是我身處在一個混亂的大團隊里。
二是不愿意表達，現在才意識到信息的整合、處理、包裝、傳達是非常重要的；橫向要跟合作伙伴表達自己的規劃、意愿、態度等；縱向要向上表達自己的規劃、成果、難處等，向下傳達傳達目標、標準、資源等。
關于發展都說程序員邁不過35歲的坎兒，所以能看到一些人迫不及待地想要擠到管理層，這好像是過去20年互聯網人留下的經驗。
對此我并沒有那么悲觀，反而覺得，如果僅僅是因為年齡到了，就擠到大廠的管理層基層，對自己的職業生涯才是最危險的。因為很多差勁的基層Leader表面上管理著團隊，實際上就是上層和下屬之間的傳話筒，團隊只不過是靠組織結構聚攏的一伙人而已；目標是上面給的，下屬是公司分配的，自身也沒有足以影響他人的氣場；沒有核心競爭力，做這種Leader的危機感要比普通程序員大的多。
就程序員這個方向來說，我覺得 35 歲的魔咒會在不久的將來被打破，這是國內行業發展的必然趨勢。現在之所以有35歲危機，根本原因是因為程序員的后備新生力量太充沛了。每年都有大批大批的畢業生涌進互聯網行業，有科班出身的，也有半路出家的，都是奔著高薪來的，這里面不乏大量的蝦兵蟹將。但由于互聯網紅利的存在，多么爛的技術都能創造出收益。 隨著國家對金融、互聯網、房地產的打壓，潮水退去，紅利消失，新鮮血液會變得越來越少，互聯網技術圈也會慢慢朝著高質量方向發展，相信五年后，只要有扎實的技術能力，即便沒有躋身到管理層，也能在行業里橫著走，想要渾水摸魚的拿高薪是不太可能了。
關于做事隨著工作經驗的增加，發現大家成長路線都差不多，都是踩著一個一個坑走向成熟的。
工作不是做作業剛畢業的大學生在做事時很容易維持大學里交作業思維。就是上面布置個任務，只要我把工作中核心主體部分完成了，就能拿個90分。但工作并不是這樣，作業要考察的是知識能力；而工作考察的是最終的交付結果。比如任務是實現一個高性能緩存系統，如果不把 API 接口及運維做好，內部設計無論多么高大上也是0分。
發現隱性成本工作上并不是做的事情越多越好，同理產品的功能特性也不是越多越好。我們在做事時，經常會通過引入一個新的工具或新的概念，來解決當前的一些問題。但任何工具和概念的引入，勢必會在一定程度上增加系統的復雜度，而復雜度的增加往往會帶來新的問題。所以我們必須要衡量，一個新事物的引入，它自身所帶來的問題，與目標問題比起來，孰輕孰重。我們遇到的最多的就是成本問題。
比如有人參考網上資料，要引入流式計算去處理日志統計問題；可目前流行的 kafka + flink 會增加下面幾點復雜度和成本：
消息隊列和流式計算的系統本身維護成本。機器、帶寬等物理資源成本。topic 和各種 job 等虛擬資產的管理成本。維護和使用的復雜度升高。數據鏈路變長，整體穩定性會下降。
我們再對照這一舉措所要解決的問題，比如日志量大不大，數據重不重要，統計的意義大不大等。進而才能決定要不要這么做，甚至是要不要做。
有技術熱情的人很容易掉進自嗨的坑里，因為技術也是有時髦性質的，自嗨有時是控制不住的。有時為了調動大家做事的積極性，自嗨一下也是沒辦法的，但重要的是要勇于承擔這自嗨的后果，不能等報應來的時候就各種甩鍋，甚至拍拍屁股走人了。
注重交付內容我之前總是單純的以為，認認真真的把一件事做好，追求極致卓越，就會有更高的回報。但卻無數次被現實打臉。因為這里好的標準是我主觀臆斷出來的，而不是客戶標準。
一件事情會有很多個維度，所以講極致卓越時，一定要有針對性；要看清哪些維度是自己喜好的，哪些維度是客戶喜好的。 我們必須要非常清晰地確定要交付的內容是什么，然后才能追求機制卓越。比如DB系統負責人，一味地追求每秒寫入最大化；而使用者的數據量可能很小很小，更希望的是DB穩定。錯誤地追求極致往往是得不到認可和回報的。
總結下來就是一定要很清楚地確定自己要交付的內容是什么，這個內容包含哪些維度，選擇最有價值的維度去做極致追求。
其實確認交付內容是一件很難的事情，它包含大量的細枝末節。包括客戶的期望是啥？客戶如何使用我們的系統？系統如何設計？我們負責維護還是客戶自己維護？如何維護？后期如何運營和升級？如何計價？客戶把系統用壞了如何解決？
如果就是某一個方面有極大的熱情，那么就不應該在乎回報和認可。因為這有些類似于藝術的自我表達了，藝術是不需要被他人認可的。
關于學習好多人都說程序員有學不完的技術，技術更新迭代的太快。其實都是胡扯。這些花里胡哨的新技術基本都大體相似，也可以說都是輪子。大多數新技術的學習手冊，跟家用電風扇的安裝手冊沒什么本質的區別，需要的時候去查閱看一眼就好，這個過程不能稱之為學習。
學習其實是一種抽象能力，從繁雜的事務中抽象的理論規律，并能應用于更多的同類事務。其實是一個信息減熵過程。
當我們學習了多個開發語言，多種DB，或分布式系統后，就會發現他們本質上沒有太大的區別。架構設計上基本都以低耦合高內聚的原則進行分層，不必拘泥于各種設計模式；性能上就是無處不在的加 cache，大鎖換小鎖消除不必要的互斥，隨機寫換順序寫，多線程并行，冪等；db 就是 B+，LSM的各種變體。之所以他們會大同小異，是因為計算機的體系結構是迭代很慢的，十年都不會變一次，而能夠最大限度壓榨物理計算資源的方案早就被前輩們探索過了。當然更深層次的技術創新也是有很多的，但是在工程領域并不常見，而且創新的頻率也沒那么高。
分層分層思路其實是一個非常通用的解決復雜問題的方式。比如管理上的職級劃分屬于分層，國家機構的劃分其實也屬于分層，我們做系統架構也喜歡使用分層，一是方便梳理系統本身，二是方便與人員組織結構對齊，三是讓系統層級與業務邏輯上的各個步驟對齊。感覺整個人類社會都是按照層級去構建的，只不過維度不同而已。
試錯最后一點關于學習想說的就是，要敢于試錯。我覺得人之間最大的差別就是，有些人能用一年的時間經歷完別人五年才經歷完的事情。勤奮自然是一方面，另一方面就是要敢于試錯。其實所有人都期望能把每一件事情做好，但這是不可能的；對于未知的事情我們總是恐懼，怕犯錯。但其實很多時候犯錯的成本并不高，大不了挨頓批評，扣點獎金。但這個試錯經歷是很寶貴的。我們可以不那么勤奮，但有想要做或是必須做的事情時，要盡早。一旦做完，下一段劇情就開始了。
閱歷使人智慧，生命的時間又那么有限，無需欣賞別人怎樣怎樣；一切隨心而動，不要讓念頭懸在那里，跟著念頭行動起來。
近兩年工作小結就分享到這里，想看更多近期工作反思總結、近一年工作小結就天下美文網。