1 comment
我正式走上職業生涯是 2011 年秋天，完成了博士學業，躊躇滿志地加入了 google。當時，我的理想是做 google 裡生產率最高的軟體工程師。為此，我列了乙個高效工程師名單，看他們每天提交的**是些什麼，以從中學習高效的工作方法。這個名單裡有 jeff dean, sanjay ghemawat, rob pike，還有一些 google 內 7 級以上的工程師。因為 google 內部源**提交全部公開，我可以看到他們每天的工作內容。
很快，從讀這些**中我認識到了一點：人每天只有八個小時工作時間，誰都一樣。其中能高效工作的時間絕對不超過4個小時。這些工程師編寫的**行數絕對不算多，但從事的專案影響大。比如 pike，大部分時間花在了審查其他成員的 go **上。而乙個剛入行的 golang 工程師，每天的任務就是寫作 go 的標準庫，今天寫 http 明天寫 sort，寫的比 pike 多很多。考核時，高階工程師因為帶領著高效團隊，每季度 okrs 上都有諸多亮點；而剛入行的工程師，只能報告一些比較瑣碎的成就。
這個觀察近乎於常識，然而對於當時的我來說是乙個頓悟：做出 mapreduce 框架的和寫瑣碎 mapreduce 程式的工程師之間的差距並不是他們的工具和程式設計效率，也往往不是教育背景或者經驗，而是他們各自的槓桿：所帶領的團隊。
問題是，沒有人會給你這個槓桿。於是，我開始觀察別人的槓桿是怎麼搭建的。
google 的芝加哥 office 有兩個技術領導：brian fitzpatrick 和 ben collins-sussman。他們合寫了一本書，叫做 team geek。近水樓台，我就拿了一本過來看。或許對於 google 之外的人來說，這本書講了許多有價值的東西，對於 google 員工來說，基本上書裡面說的就是公司每天實踐的，因此讀來覺得都是常識。這讓我突然領悟到，其實所謂的團隊工作，或許說白了就是正確地運用這些常識。
在實踐中運用常識遠比想像中的難。有一次在搏擊課上，師傅讓我和某個拿過法式拳擊世界冠軍的師兄對練。他手腿都很長，出拳又快，根本拿不到破綻。為了不被首輪打倒，我不得不滿場跑著閃躲。躲著跑過師傅的時候，他就說了一句：「你只管出拳，不出拳永遠贏不了點數」。其實這是每個學搏擊的人都知道的常識，卻因為一時的恐懼徹底忘了。做技術領導時也是一樣，許多我們知道的常識性的東西，一旦遇到複雜情況，我們往往依賴於舊習慣和情緒反應，忘了要解決的問題，忘了運用常識做出正確的判斷。
常識是可以習得的，因為每個人都有包容常識的心性。問題是，所謂常識，是名常識，實非常識。根本沒有一本叫做「技術管理常識」的書，讀完就事理無礙了。在領悟到技術管理其實是運用基本常識之前，我買了一大堆的關於技術管理的書，幻想能夠博聞強記速成。想明白「習得」這一點，讓我輕鬆了好多：這不是入學考試，慢慢積累最省時省事。就像練習武術一樣，最強的鬥士絕不是看書最多或者理論最強的，而是訓練時間最長的。
我曾經也醉心於一些管理方法。比如說，kanban 管理法是照搬了豐田在七十年代的高效率生產模式而提出的。06年第一次讀這個管理方法的時候崇拜無比。到了2023年，豐田汽車在世界範圍內發生了多起質量問題召回的事情，使我重新審視這個問題：任何管理方法都是為了解決某些類問題而催生的。問題變了，不管以前多麼神奇的管理方法都會變得一地雞毛，因為管理方法不能脫離要解決的問題。
也就是這個時候，我重溫了溫伯格的《技術領導之路》。這本書對於我來說最有價值的一點，是讓我體會到儘管管理方法成千上萬，歸根到底需要一些「元方法」去支配。比如，書中提到了乙個大家都明白的元方法：寫日記。技術領導者每天寫日記，記下每天的活動，反思一些事情。儘管寫日記並不能直接解決技術管理上的難題，卻開啟了反思之門，也把許多事情前因後果連線起來。比如，通過在日記裡反思一些會議的效率，我開始有意識地反思高效率的會議和低效率的會議的差別，並主導一些會議的日程。顯然，真正的問題不是要不要設定議事日程（元方法），而是學會怎樣設定乙個特定會議的議事日程（解決問題的方法）。而後者，只能通過設定議事日程學到。
我是乙個理科生。理科生理解世界的第一工具是模型。世界過於複雜，人腦計算能力有限，只能付諸模型抽象簡化。技術管理作為技術（工程學）和管理（自然科學）的橫切點，自然免不了各種各樣的模型。技術管理的模型本身多種多樣。人月神話模型，人件模型，豐田模型，溫伯格模型，agile 模型，lean 模型等等不可列舉。對於乙個技術管理人員來說，幸運的是，所有的模型都是錯的，所以即使不知道這些模型，也未必遺漏了什麼重要的。不幸的是，有些模型的確比較有用，所以知道一些還是有好處的。
正因為此，我開始收集一些工作中積累的管理模型 (pattern)，像 gof 的 design pattern 一樣，列出要解決的問題，模型，和自己的實現。我收集了不少細碎的模型。有時候覺得過於細碎，不足為外人道也；有時候又覺得好像還是有些用處的。
就這樣，在不斷的寫作懶惰症中過了三四年。直到最近，說來也巧，在檢查乙個 bug 的時候發現有某使用者呼叫 fitbit 的食物記錄 api 中試圖存下 「
**：
技術管理 開篇
在我們工作3 5年左右，陸續都會帶領一些小夥伴，隨著帶的人越來越多，會逐步成長為管理者。在成長為leader以後，很多的小夥伴都不適應，從原來的做好自己轉變為帶著團隊做好這個層次上的轉變。我想成為乙個怎樣的人?我想要乙個怎樣的團隊？每個人都有自己的特長和喜好，比如我喜歡與人溝通交流，我喜歡帶著團隊一...
技術 管理和技術管理
與 老大 一起談軟體行業 和 我為什麼寫 致it同仁 軟體行業的另乙個真相 中談到，軟體設計是一門藝術，也許，很多技術在做到很高的境界時都是一門藝術，也就是說很多技術在其更高層次上都是相通的。由此看來，技術與管理在高層次上也可能存在很多共性。是哲學？乙個完備的組織架構通常存在管理與技術兩方面的內容，...
技術管理之道
一年管理成富翁，十年技術一場空！你沉迷於技術不能自拔，幻想成為一名受人尊敬的架構師，但你發現時間 精力越來越不夠！你身體透支，做著 crud，感覺自己沒有技術成長！開啟你的小圈子，你猶如井底之蛙。你時常焦慮，你時常說要努力！然而並沒有什麼卵用，你最終活成了乙個屌絲。不破不立，從今天開始，走上技術管理...