程序員成長有很多外因，好的時機、好的公司、好的同事，會讓你的成長更順利。
這次我們聊聊剛入行的初學者該怎麼提升自己，用個流行的說法，咱們來談點觀念，理清概念，才能更好地成長。
適合初學者的幾點提升要訣
提高業務能力
對初學者，入行後最重要的肯定是抓緊提高自己的業務能力。對校招渠道入職的新員工，公司的期望一般不高，能幹活，有潛力即可。
新員工的第一要務，當然是要迅速上手。在一箇中小項目裡，上手一般不是太大的難題。
我們看看 UI 開發的例子。初學者的第一份工作，經常會是簡單的邏輯、菜單、UI 等等。
它們共同的特點是不難但很繁瑣，一般只要照著前人的工作，依樣畫葫蘆，就能做得八九不離十。
在這個過程中，新人可以很好鍛鍊自己在軟件工程方面的實踐，學習如何同團隊成員配合；如何和跨領域的策劃美術交流，儘快熟悉遊戲的設計、開發、構建、測試等流程。如果項目快上線了，那還能順便鍛鍊身體，加班熬夜。
關於做 UI 和邏輯，初學者常常抱怨，沒有技術深度，不出彩，但特別繁瑣，做起來很累。屬於做好了沒功勞，做砸了要背鍋，摧殘人性，讓人痛不欲生。
這也是一個老生常談，簡單的工作也需要有人做，如果有心，在 UI 開發裡面也可以找到個人的積累和發展，有幾個事情不妨嘗試一下：
提高自己的效率
做得更好、更快、更少 Bug。有了效率，就能提高質量。以前見過新的同事，學有餘力，做一個功能，往往會自己發揮，做兩三個不同版本讓 Leader 挑選，這樣的同學很快就能脫穎而出。
提高程序團隊的效率
看看 UI 從設計、開發到驗收，有什麼流程可以改進，提高功能開發效率。Leader 或者其他 Senior 程序員往往有其他領域要關心，沒精力關心這一塊。
讓領導放心不就是我們職場應盡的義務麼，在這個子領域，初學者也有機會發揮的。
或者你也可以看看是不是能做通用控件，讓整個 UI 團隊效率更高。通用控件由於要考慮方方面面的需求，開發有一定的難度，能很好地提高個人的能力。
提高項目整體效率
UI 和邏輯上更多應用數據驅動，合理架構，減少硬編碼，把一部分UI編碼工作變成配置工作，開放給策劃，既減少了工作量，策劃也會覺得更靈活。
分開邏輯和表現代碼，便於調整功能，也方便寫單元測試。做點力所能及的重構，關注一下 UI 的內存和性能，別給整個項目增加不必要的風險，這都是可以嘗試的。
無論在什麼職業中，業務能力總是最重要的。有了業務能力，才能贏得大家的尊重。即使第一份工作內容並沒那麼有深度，也要認真做好它，從中學習，快速成長。
持續學習，找到 Unbroken Time
本職工作做好之後，千萬別滿足。我想聊的下一個話題，就是關於持續學習。
程序員族群，早就身處在一個終身學習的時代，入行就是焦慮的開始，持續的學習，不能保證百尺竿頭，但至少能迴避逆水行舟的惶恐。
雖說程序員都在學習，學習的質量差別還是比較大的。相當多的程序員並沒有良好的學習習慣，忽略了提前儲備知識的過程，只是被動的學習如何解決迫在眉睫的問題，掌握明天上班要用的技能。
學習和積累的主題以後單獨展開，這裡只說一個小習慣，也是個人效率裡一個很重要的概念，找到你的不被打斷的時間。
程序相關知識往往燒腦，沒有沉下心，便不能理解。一整段不被打擾的時間，是必須的。
但碎片化的時代，整段時間早被手機的滾滾洪流碾得粉碎，大家前仆後繼，把完整時間碎片化，刷刷朋友圈，回個微信，收個郵件，一個小時就過去了。
我們要做的，是儘量給自己創造條件，空出不受打擾的時間，用個人的意志抵制碎片化。
我工作早年使用的是公交車等座位大法。反向坐公交車到終點站，排個座位，上車，拿本書慢慢看。
那年代心還很靜，手機還被叫做大哥大，沒什麼車上娛樂。快快翻過看得懂的頁，看不懂的低頭想想，每個工作日有那麼一個小時可以靜心閱讀，不知不覺幾年間啃掉了很多艱澀難懂的大部頭。
後來開車上下班就悲劇了，嘗試了各種方法，但還是沒法專心閱讀，車上的時間只能聽聽 Podcast。
要深度學習，要省出不被打擾的時間。實踐下來最有效的還是早到公司法。早上提前 30 分鐘從家出發，路上車沒那麼堵，往往還可以省出 15 分鐘路上的時間。
到了公司也很清靜，千萬不要收郵件，也別去倒茶，要警惕碎片化陷阱。趕緊拿上要看的書，離開你的電腦，離開你的手機，去會議室學習。
另一些能用的方法包括早起法，晚睡法，打出租車上下班法，一個人去很貴很清靜的館子吃飯法等等，大家可以自行發揮。
有了完整的不被打擾的時間，可以深度儲備業務知識，可以橫向掃描行業進展，可以回顧工作得失，可以總結輸出知識。
雖然每天幾十分鐘不起眼，但如果能堅持幾年的話，你一定能看見自己的成長。
信息樞紐（Info Hub）
下一個對我很有幫助的觀念，是需要努力成為團隊中信息的樞紐。
信息樞紐是我的一個生造的概念，靈感來源於 HUB（集線器）。網絡中的集線器，彙集了所有的信息，再廣播給其他設備。
對我們信息從業人員來說，你做好了本職業務，積累了廣泛的跨領域知識後，應該考慮如何逐漸讓自己變成團隊內開發知識溝通的中心，讓自己在團隊中更不可替代。
回到我的個人經歷，我在 2001 年作為公司前幾批開發人員，接觸 Unreal2 引擎。
當時的項目使用 Unreal2，我做邏輯，做網絡對戰，有了持續的積累後，我很快在 Unreal 的邏輯開發上積累了豐富經驗。
雖然在整體開發經驗方面我還是比不上其他開發者，但在 Unreal 邏輯這一塊我比較專業。
我在公司內做了一些相關知識的分享，然後在後續的項目裡面堅持到處看看，幫助其他同事 Debug ，或者介紹相關的模塊，讓他們也能快速上手。
逐漸的，我發現了一些有趣的變化。很多同事碰到這個領域的知識，有問題都會先來諮詢我。當然這些問題我也並不是全部能回答的，我擇其易者答之，其不易者學之。
因為手頭工作也很多，對那些不瞭解的問題，我通常會說讓我研究一下，抽點時間看看能不能解決，然後再回復同事。幫助大家次數多了，我就自然成為了 Info Hub。
成為信息樞紐以後，對團隊的好處顯而易見，你潤滑了團隊，順暢了知識通路，自身價值變得更重要。對個人的好處不那麼明顯，卻更重要。
各類信息在你這裡集結，回答已知問題可以鞏固你的知識，研究未知問題可以擴展你的邊界，信息在你身邊流過，自然可以滋潤你的認知。變成更好的自己，不就是我們一直的追求？
當然，成為 Info Hub 並不容易，需要個人努力，也需要一些機緣巧合。新項目、新技術的早期拓荒者，很有可能成為信息樞紐。
但新項目和技術有一定的風險，不是新的就是好的，新方向會失敗，會毀了你統治信息的野望。
於我而言，在 2001 年這個節點，Unreal 也許就是一個新方向，在 2001 年後的八年裡，熟悉 Unreal 給我帶來了巨大的回報，甚至很多影響點點滴滴影響了開發自己引擎。
如果運氣並不那麼好，研究了沒落的技術，參與了失敗的項目怎麼辦？事情沒有你想象的那麼糟糕。
沒落的技術，即將無人問津，但它是細分領域的知識，領域越窄，越少人懂，越方便你成為專家。
總結一下這個技術為什麼失敗，橫向對比一下其他成功技術，談談趨勢，都能讓你自己提高。
至於失敗的項目，就更無所謂。項目的失敗，意味著公司或者團隊損失了機會成本，但項目中的每一個人，確確實實得到了成長，吃一塹就能長一智。
時常總結，在失敗中找到自己的成長，才是我們要關注的。
我剛開始用 Unreal，第一個項目是被公司砍掉的，也沒有任何人有把握說，Unreal 將來能得到巨大的應用，但積累在那裡，說不定哪天會給你帶來豐厚的回報。
再來談一個對初學者成長有幫助的概念。
跨界和好奇
如果讓我總結怎麼讓自己變得更有價值，跨界無疑是一個非常重要的關鍵字。
所謂的跨界，是指擁有多個和本專業不同領域的開發知識，並可以靈活運用在開發過程中。
當你有了跨界的能力，就可以在開發和交流中，利用跨領域的知識，幫助團隊更好的溝通、設計、實現功能。
跨界的意義有幾個，重要性依次遞增，增加溝通效率，提升產品質量，超越已有認知。我們分別展開討論。
增加溝通效率是最容易理解的，遊戲開發需要多工種合作，大家說著不一樣的行話，做著不一樣的工作。工種和工種之間，有壁壘，阻礙了交流。
擁有跨界的知識，邏輯程序員瞭解一點關卡策劃的工作，渲染程序員懂一點技術美術的工具，引擎程序員接手一下工具程序員的模塊。
這些跨界的認知，都能很好提高團隊溝通效率，幫助不同職能同事更快的達成共識。
擁有足夠的跨界知識，溝通會更精準，也不用經常拉上其他同事一起討論問題，減少溝通環節，降低溝通中的失真，就順理成章了。
人和人的信任，本就是從工作的合作細節開始，你會發現那些擁有跨界知識的同事，不知不覺間，就成了項目中心，加薪升職贏取白富美，從此過上了幸福的生活。
提升產品質量是下一個水到渠成的事情，當擁有了別的領域的知識，我們在設計和實現功能的時候，就可以考慮到用戶的需求，把手頭的工作做到更好。
舉個簡單例子說明一下。比如開發編輯器時，很常見的一個需求，就是編輯參數的界面。
比如我們要調整一個遊戲內物件的參數，最常見的做法，就是選中這個對象，彈出屬性表單，可以調整參數。
這個功能所有引擎都有，一般的實現方式是在引擎內表示對象參數的時候，對每一個參數有元信息描述，表示參數的類型、編輯方式、取值範圍等等。
屬性表單彈出後只需要遍歷這個對象的參數元信息，然後為每個可調整參數創建顯示和編輯的控件即可。
有了基礎功能，下一個訴求，是一個對象會有非常多的參數，不是所有參數都需要暴露給編輯器編輯，全部暴露出來反而降低開發效率，容易誤操作。
所以多數引擎一般在參數元信息加上標誌，需要暴露的參數，才會被編輯器顯示在屬性表單內。
到目前為止一切都還好。但策劃又提出新要求，同一個對象，在另一個特殊的編輯界面，也要調整參數，這次需要顯示的參數，和普通界面需要暴露的參數不一樣。
這個需求的本質，就是針對同一套數據 Model，定義多個不同的 View。如果按照原有的元信息系統發展下去，我們要加上新的參數標誌，讓這些參數開放給另一個 View。
當 View 變多的時候，整個設計就會比較臃腫，每多一個不同的 View，就需要修改 Model 的元信息，這個路徑有點長，會動到已有的結構。
這個思路有點不對，為什麼不同的 View，需要動到數據的 Model 呢？不同 View 的複雜性，就應該放在 View 裡面啊。
當工具程序員設計參數元信息和屬性表單的時候，如果能提前想到策劃可能有這樣的需求，那麼設計角度就可以做點調整。不必通過在元信息上打標記，而是搜索的方式。
比如我們 Mac 電腦上的 Finder，它有智能文件夾，本質上就是一個組合的 Filter，用 Search 來進行文件的篩選，不同的搜索，保存成智能文件夾，就可以快速便捷的歸類文件。
同樣，對我們的屬性表單，我們也可以使用正則表達式來進行屬性的篩選。這樣針對不同的 View，只需要定義不同的過濾表達式就可以了。
正則表達式還可以數據驅動，策劃要什麼參數就改改配置文件就好了。正則表達式來定義 View 的內容，既強大，也精準。
所以當你擁有了跨界的知識，瞭解用戶的需求，瞭解其他領域的巧妙設計，就有可能設計出更好的系統。
超越已有認知是跨界更重要的好處，可以做出不同的設計，或更精簡，或更高效，或更突破，或兼而有之。
舉幾個例子：
- 尋路問題是個搜索問題，可以用來計算最短路徑，那我就可以用它來計算聲音在室內的傳播了。
- 序列化不僅僅可以用在保存上，也可以用來做垃圾回收的標記，做文本數據和配置文件的打包和二進制化，做數據文件的壓縮和加密，做項目廢舊資源的標記和刪除。
- 誰說我們一定要在同一個進程裡讀寫數據，為什麼不在另一個進程裡面統一讀寫數據，便於多開遊戲進程可以共享讀取的Cache，也可以對併發的讀取進行重新排序，降低磁盤尋道開銷。
既然跨界知識如此重要，如何來培養自己的跨界能力呢？我給的答案是好奇心，對技術有好奇，多看多問，多想多總結，自然就跨界了。
初學者最重要的品質就是好奇心，幫助你探索未知的邊緣。遊戲開發的客戶端技術，業務領域眾多，我們簡單細分一下，就可以分出邏輯、UI、工具、渲染、引擎、物理、音頻、動畫、AI、構建等等領域。
相當多的方向，既廣又深。再考慮到和周邊業務團隊接口，還需要對後臺技術、美術技術、策劃領域有一定的瞭解。
對技術的好奇，可以幫助你加速跨越崗位之間的邊界。試著放縱一下自己的好奇，完成本職工作之餘，向對面的工作內容張望幾眼。多看看，就懂了。
我從業最初工作內容是 UI 邏輯，逐漸做了 Unreal 引擎上的開發，先寫腳本和邏輯，然後支持關卡策劃做邏輯相關開發，工作之餘，遊戲 Crash 時候，就順便往腳本解釋器裡面搗鼓搗鼓，Debug 一下腳本編譯器和解釋器。
引擎程序員和邏輯程序員之間並沒有分明的涇渭，看幾次，沒啥學不會的，逐漸也就熟悉了相關模塊，再逐漸拓展到引擎其他模塊，哪裡有問題，過去看幾眼，不懂找高手問問。
再不懂，放一下，職業生涯很長，現在不懂的，將來會懂，保持好奇，總會到彼岸。幾年下來，也就把 Unreal 引擎方方面面磨了個透。
任何一個大項目，大引擎，都是知識的寶庫，不用捨近求遠，認真做好手邊的項目，就會成長。如果有幸能參與到一流的項目中，成長速度會更快。
我的職業生涯前幾年在 UBISOFT 工作，參與了很多 AAA 項目，即使沒有太多的主動學習，眼界和能力也能有很大的增長。如果沒有機會參與高端項目，也不需要氣餒。
遊戲技術領域的知識相當公開和透明，關注 GDC 以及其他開發會議，留心歐美新出版的技術書籍，定期掃一遍，就大致知道技術圈發生了些什麼事情了，找個感興趣的領域深入看進去，堅持幾年，就會有很大的提高。
總結一下這寫的一些觀點。劃一下重點，這幾道是送分的必考題：
- 初學者要專注提高專業能力，即使是簡單的工作，也能提高自己的能力。
- 培養自己對技術的好奇心，多看看，提升自己跨界的能力，對項目或者對自己都好。
- 培養良好的習慣，找到不被打擾的時間段，持續學習。
- 試圖成為信息的集散地，幫助別人，才能幫助自己。
技術瓶頸期如何轉崗轉職？
前篇講了從 Junior 到 Senior 程序員的成長過程，現在談談轉職。從我自己的工作經歷來看，工作了 5-6 年以後，就遇到了技術上的瓶頸期。
當我開發很久的邏輯和 AI，也包括一部分網絡對戰模塊，在幾個不同項目中鍛鍊後，多數相關的細分領域都接觸過了。我逐漸對這些技術提不起興趣了，於是想轉崗去做點引擎相關的事情。
職場新人是一張白紙，有機會在不同領域換崗位。而工作幾年的老人，常常有自己擅長的領域，不如小朋友可塑性強，且體力也不如年輕人。
這時候要轉新的崗位，就有一定的難度。常常看見很多人想做渲染、想做引擎，但卻沒有太多的知識儲備。
問他們為什麼不提前準備，他們就說：工作很忙，沒空學習渲染和引擎，但你不讓我做一下，我沒有經驗，又怎麼會有能力做好渲染和引擎呢？非常遺憾，這個邏輯是錯的。
這裡有一個必須注意的地方。在轉崗這個事情上，公司是不會為了你的理想和野心買單，他們只會為你的能力買單。
我們把它翻譯成人類的語言，就是公司一般不會僅僅因為你想轉崗就讓你轉崗，只有你具備了新崗位需要的能力，才有可能讓你轉崗。
舉個例子進一步說明，職場潛規則裡，如果有幾方利益相關團隊要推動一件事情，潛規則就是哪個團隊受益多，哪個團隊就會更主動推動這件事。
你的小算盤是轉個崗，學點新東西，公司想的是每個人安分做一顆螺絲釘，做好自己最擅長的事情，工作效率才高。
雙方利益有一定的衝突，這時候如果你表示，我已經具備新崗位的能力，對公司來說，只不過是把你這個螺絲釘換了一個位置，而不是重新在新崗位造一個螺絲釘出來，這樣公司會容易接受得多。
所以結論就是，想轉崗，先自己學，能勝任了再去提。
回到我的個人經歷，由於參與的幾個項目都是使用了 Unreal，所以技術上有比較好的一致性。
由於自己平時也比較重視跨界知識，引擎那一塊基本也有一定的熟悉度。於是和領導提了一下想轉做引擎的事情，領導說忙完這個項目就讓你去搞引擎。
很快找到了一個好機會，開始去 Splinter Cell 4 項目做引擎。接到的第一個任務，是獨立把 Unreal 引擎移植到 Xbox360 的 Alpha 版開發機上。
當時接到任務，虎軀一震。Xbox360 架構和 PC 不太一樣，當時 Epic Games 官方也沒有 Xbox360 版本的 UE 可用，我們找了一個其他遊戲 Xbox360 移植參考，但參考價值不大。
因為 Ubisoft 喜歡深度定製引擎，Unreal2 的引擎部分已經被 Splinter Cell 組改得面目全非，估計連 Tim Sweeney（Unreal 引擎的爸爸）都認不出這是 Unreal 了。第三方的引擎移植無法直接參考。
那就開始搞吧，拉了一個分支版本，二百萬行代碼，無從入手，先編譯通過再說吧。
我建立了 Xbox360 的項目，開始編譯，不停修改編譯錯誤，一時搞不定的大問題，就先把整個模塊註釋掉，做好筆記以備後續修復。
當時開發環境也比較差，Xbox360 編譯器 Bug 還挺多，而且預編譯頭文件設置有 Bug，預編譯頭文件非常小，且無法通過參數擴大。
這就導致大量代碼無法放入預編譯，偏偏 Unreal 的結構重度依賴預編譯，我的代碼編譯速度極慢。編譯的時候就只能看看文檔，什麼都做不了乾著急。
我沒日沒夜搞了 1 個多月都沒有完全編譯通過項目。每次開週會的時候，都覺得自己快死了，翻來覆去就只能彙報說自己還在和編譯器搏鬥。
遊戲引擎的前期移植，不比大規模開發，前期移植通常只能讓很少的人參與，基本無法並行操作，你都編譯不過，別人怎麼插手。
如果我搞不定，就要換一個人來搞，浪費很大。估計老闆也是心裡罵娘但嘴上不說，鼓勵幾句讓我繼續搞。
心理壓力是一方面，能力短板也是另一方面的問題。雖然我做了很多引擎技術的提前儲備，真正面對整個引擎規模的移植，還是發現缺口不少。
我在業餘時間拼命補課，把不懂的東西學會，才能推進。但很快又碰到新問題，有些領域是 Unreal 專業領域的知識，並非通用知識，很難學習，也找不到人諮詢，而且涉及到的面比較廣，沒有辦法在短時間裡面全部看透。
這就需要我在信息不完備的情況下做技術決策，這個模塊大致應該往什麼方向做，如果出了問題怎麼辦，我可以怎麼回溯。
做一兩個決策還好，但往往是一個決策套著一個決策，前後的技術決策有依賴關係，要回溯就要一起推翻。
沒有什麼堅實落地的技術決策，就好像走在半空的索橋，每一次搖晃，都在動搖我信心的根基，做到後來都懷疑人生，覺得這活真不是人乾的。
好在終於還是編譯通過了...然後就是調試程序，要讓引擎運行起來，哪怕沒有渲染也不要緊，只要有主循環跑起來就好了。只有那樣，更多的同事才能參與進來幫忙。
後面斷斷續續又有了很多的障礙，Xbox360 的內存模型以及 Alpha Kit 的 Bug，序列化的 Big Endian 和 Little Endian 的區別，Fix Function Pipeline 在 Xbox360 裡面完全被去除了，性能的問題等等。
硬著頭皮一一搞定，終於勉強在電視屏幕上畫出點像素，雖然各種飛面，光照全錯，一會就會 Crash，但至少把主循環跑起來了，當然也是基於很多不知道是正確還是錯誤的技術決策。
先快速走通流程，比什麼都重要，鋪好了路，咱們的大部隊就能一起來和我並肩作戰啦。
當時已經和主幹的開發版本分開兩個多月了，於是又花了 2 周來 Merge 最新的改動，整個開發團隊那時候就有 20 多個程序員，幾十個美術和 10 多個關卡策劃瘋狂的上傳，Merge 的過程也是非常不順利。
Merge 了幾輪，才勉強追上項目的進展。然後趁大家週末休息的時候，一口氣上傳了所有的改動，還要抓緊測試看看主幹版本，帶上了 Xbox360 的代碼，是不是還能編譯，是不是還能正常運行。相關的工具也都需要簡單測試一下。
忙完這一切以後，自己有了非常大的變化。最重要的變化，是終於有了技術上的自信。覺得沒什麼是自己搞不定的了，只要給我足夠的時間。
尼采說過，殺不死我的，只會讓我更堅強。做過一個規模足夠大的工作，在絕望裡掙扎過，這樣的經歷非常能鍛鍊人。
那幾個月整天低頭 Coding，基本不用和別人說話，一坐就是一天，和編譯器鬥，和 Xbox360 Kit 鬥，和 Unreal 鬥，經常陷入困境，也時不時會有突破，隨時進入心流狀態，收穫自信和滿足。
現在回憶起來，那幾個月也成為我技術歷程中最大的一個飛躍。
今後的很多工作中，有了這個自信，就開始敢在技術上決策，在團隊裡面，有些事情自己搞不定的話，別人也很難搞定，也就不再想太多。和團隊也逐漸建立起了信任，大家就更願意讓我做決定。
做到這一步，整個引擎勉強能跑，但沒什麼東西是正確的，渲染模塊還是一團混沌，邏輯方面都沒有正確工作，還需要艱苦的工作。
後續還需要把我一路 Rush 過程中欠下的技術債一一償還，把整個版本弄成 Xbox360 上可以順利跑起來，再做架構調整，適應新主機的新架構，充分利用多核框架。
2005 年搞多核引擎框架，還是個高科技。很多可以做的，很多可以學習的。非常可惜，由於工作上的調整，我被調離了這個項目，去另一個 FPS 小項目做 AI Leader。
這個經歷下面接著聊，主題就是從 Senior 程序到 Leader 的過程中，又有什麼是重要的。
快速總結一下中心思想：
- 公司不為你的野心買單，為你的能力買單。你想要什麼，先讓自己能配得上它。
- 經歷過絕望掙扎，才能變得更強大，迎接挑戰，建立你的技術自信。
如何做好技術管理？
上面聊到，好不容易轉職，做了一陣子引擎移植，漲了很多經驗，結果做了一半被公司調動去做另一個項目的組長。
技術專精到技術管理，並不是那麼順利。不是能做好技術攻關，就能做好技術管理。這裡聊聊在這個過程中的收穫和成長。
我接手的團隊大約有 10 人左右，在一個 Unreal 引擎開發的 FPS 項目中做 AI 邏輯。整個項目團隊規模不到 100 人，程序團隊就分了三組，引擎、網絡和 AI 邏輯。
新角色的定位，是一個衝在一線的技術管理職位。這也是我第一次做 Leader。
對我來說，擺在面前的難題有幾個：
- 團隊融入
- 個人效率
- 大局觀
團隊融入
先要做的是團隊融入。UBISOFT 那段時間的人員流失不多，國內強力的網遊公司不多，沒競爭力，所以組長級別以上的都是熟人，合作多年，不存在什麼問題。但組員就比較麻煩，多數都是新加入公司的，不知道能力。
和軟件開發一樣，我融入方法是小步迭代，逐步瞭解團隊成員的能力。對不熟悉的同事，分配一點簡單的工作，瞭解能力的同事，可以領一點更困難的工作。然後定期跟進後續的，過一段時間差別就很明顯了。
如果把開發者能力作為 Y 軸，把積極性作為 X 軸的話，我們就可以構建四個象限，把開發者們一一對號入座：
- 積極且能力強的，明顯學有餘力，保質保量完成工作，而且非常積極，主動來要新的任務。
- 積極但能力弱的，做得很努力，不是很能跟得上節奏，但也是非常投入。
- 不積極但能力強的，能比較快做完安排的任務，然後也不幫別人，也不來彙報，自己在角落 happy。
- 又不積極且能力弱的，組裡倒是沒發現，也是萬幸。
瞭解了幾類人，就可以分別用不同的形式管理：
- 積極且能力強的，可以給更難的任務，讓他放手去做，然後主動彙報進展即可，平時也不用太多催他，能搞定的自然能搞定，不能搞定的他也會提前彙報。
- 積極但能力弱的，給一些稍簡單的任務，同時加強輔導，幫助他在技術上能提高，多回答他的問題，給他更好的個人發展方向。
- 不積極但能力強的，是比較難處理的。任務可安排稍難的，但要特別注意迴避那些需要多方溝通、模糊地帶的任務。
- 此類同學往往比較懶，不善於或者不願意推動事情，經常會卡住。然後要多跟進，除了正常的 daily/weekly 的彙報，還要常常關心一下他的進展，讓他了解到，Big brother is watching you。
- 不積極且能力弱的，試試能不能挽救，不行也只能放棄了。
那怎麼能準確的判斷員工是哪種屬性呢？新團隊的磨合，其實就是一個彼此試探的過程。
你做得好，就領更多的任務，我對你信任+1；你做砸了，我就給你更簡單的任務，信任-1。
主動積極彙報和領任務有印象分+1，看見你偷懶進度慢就印象分-1。細心觀察一陣子，就很快有準確結論了。
而且猜錯也沒有關係，這是一個持續調整和逼近的過程，這次錯了，下次改回來就好了。
這是一個主觀判斷，也許有些同事和你合作就是表現不好，有些同事和你工作就會有超常發揮。但沒關係，管理就是一個比較主觀的事情，在你的團隊裡，怎麼用人還是由你來判斷的。
個人效率
下一個問題是個人效率管理問題。之前做開發者，同一時刻需要跟進的事情並不是那麼多，一個簡單的 To Do List，或者往桌上貼點報事貼，基本就能把要關心的、要搞定的事情都跟蹤起來了。
做了 Leader 以後明顯不一樣，同時要關心很多事情，而且不同的事務，輕重緩急不同，時間屬性不一樣。
怎麼對任務進行合理的分類管理，是擺在面前的一個大問題。我嘗試了很多個人效率管理的手段，最後找到 GTD 系統，能滿足我的需求，這是我的一個非常重要的 Life Changer。
我翻了國內外論壇的幾千篇 Mailinglist，接觸到各種奇奇怪怪的 Lifehack 理念，嘗試了幾次，成功實踐起這個流程，極大地改變了我的生活和工作。
個人效率管理系統，本質上，是一個減壓系統，降低你的焦慮，幫你跟進瑣事，讓你把精力聚焦在真正需要思考的事情，而不用擔心又遺忘了什麼承諾。
很多人會覺得個人效率管理太麻煩，生活不就應該是自由自在的嗎？我認同的卻是，自律才能得到自由，個人效率管理是通向自律的一扇窗。
對每一個認真對待生活和工作的職場人，應該要去了解一下適合自己的個人效率管理系統。
GTD 也許太龐大，太重度，不適合你，那就做個更簡化的系統，很多理念是有價值的，當你知道了，實踐了，就再也回不去原來那個紛亂無序的生活。
GTD 系統就不展開說了，書籍、討論非常多，也有很多以 GTD 為核心做了精簡的管理系統。
只提幾個重要的觀念：
- 好的個人管理系統，可以幫助大腦減壓，把對他人或對自己的承諾記下，就可以從腦中 unload 這些承諾，降低了記憶負擔，真正可以做到Mind like water，關注手頭工作。
- To Do List 是有 context 的，本質上是為了減少使用 list 時候的無效精力開銷。這個我模模糊糊也知道，但一直不知道如何合理分類。
GTD 給了非常好的示範，類似 Errands、Waiting For 列表，給很多不知如何分類的任務以最好的歸宿，真正做到以儘可能低的成本，跟進儘可能多的事情。
- Next Action 是推進很多事情的關鍵，但凡執行一件事稍有阻礙，我們就可能拖延。分解 Next Action 可以降低這個阻礙。
當然我見過好多有才能的人，並不重視個人效率管理，依然取得了巨大的成績。
每個人有自己的活法，一套好的個人效率管理系統，會增加你人生的吞吐量，要想富先修路，沒有 I/O 怎麼能升職加薪呢。平凡的我們，通過合理的效率管理，也許就能在職場上走得更遠一點點。
大局觀
大局觀是一個比較難培養的能力，不在其位，不憂其心，就不會有機會鍛鍊。
第一個和大局觀有關的是跨團隊協作。項目中不只有你一個團隊，AI 邏輯團隊作為一箇中央樞紐，要把關卡策劃服務好，對接 UI 美術，把引擎功能包裝整合，配合 Online 組開發 Match Making，和每個組都有或多或少的聯繫。
很多時候，本團隊工作安排最優不代表全項目工作安排最優，跨團隊的合作，該強硬的時候要強硬，該讓步的時候要讓步，一切以項目利益最大化為目的。
由於 Leader 們私交都不錯，合作多年，相對來說跨團隊合作都還好，沒有太大的問題。
第二個和大局觀有關的問題是對自己團隊工作的把握。什麼時候該鼓勵團隊探索一些先進技術，並且在研究不順利的時候決定繼續還是喊停，什麼時候應該保守一點，收斂需求，確保能完成相關特性，這就是一個典型的例子。
這方面要做好，需要有廣泛的領域知識，也需要一些跨界知識，更需要多個項目的經驗。
因為做決定的時候，也是在信息不完備的情況下，一個好的決定也需要一點點運氣。
第三個和大局觀有關的問題是控制團隊工作節奏。要試圖理解整個項目階段，我們團隊的工作對項目交付有什麼影響，什麼時候我們是瓶頸，要加速做，什麼時候我們有閒暇，可以放鬆一下，做點長遠技術投資或是清償一下技術債。
當然，AI 和邏輯團隊永遠都是瓶頸，所以也不用想太多，努力工作就是了。
第四個和大局觀有關的問題是組內的工作交付問題。有些同事雖然很努力，但總不能交付理想的成果，是換人來做，還是隻好選擇原諒他？
換人來做意味著新同事要重新熟悉這一塊的工作，老同事會覺得很沮喪，不被組織信任。換了新人如果搞不定怎麼辦？
有幾種可能，要麼這件事就是不容易搞定，要麼第二個同事還是不給力。所以換人做的話，一定要確保新接手的同事是信得過的，避免再次出現換人。只要新接手同事沒做成，就告訴自己此路不通，我們想辦法繞路。
第五個和大局觀有關的問題是你要控制你自己。Leader 相對來說總是一個團隊技術最好的，看見大家搞不定事情總想著要衝上去幫忙，找一下智商優越感。
也很正常，人總是希望做自己擅長的事情。一起幹活本沒有錯，也能很好提高團隊士氣，但是時機和工作內容要選好。
千萬不要選擇在關鍵路徑上的任務，如果搞不定會影響整個項目進展。因為 Leader 在中前期總有各種重要的技術選型和決策要做，在中後期總是陪加班和調配資源，應付突發事件，哪件事都比上去搞定幾個任務重要。
如果手頭有關鍵路徑任務，往往都是最難的，工作中又無法抽出整段時間專心做，很可能會拖累整個項目。
找點可以獨立的事情，可以是比較難的長線任務，也可以是沒有太多依賴的疑難問題 Debug，或者是做做優化，這些事情既能找到滿足感，沒時間搞定，也不會對項目有太大沖擊。
總結一些中心思想：
- 瞭解好組員，用最適合的方式管理大家。
- 個人效率管理對提高個人吞吐量至關重要，降低自己的焦慮，幫助自己成為一個更可靠的人。
- 培養大局觀，做好協作，把握工作方向，控制工作節奏，關注組內同事交付，控制自己想做技術的衝動。
緩解焦慮，走出舒適區
做完那個項目的 AI 團隊 Leader，後續繼續回 Splinter Cell 組做引擎相關工作。
Leader 已經做好了多線程的架構，我進一步在 Xbox360 上做優化，很多有趣的優化點或者高難度的 Bug，在 Bug 往事那裡都說過，就不重複了。
後續項目在一個很小的項目裡面做主程序，目標是 4 個月完成 Rayman 瘋狂兔子的 Wii 到 Xbox360 移植，並提交審核。
之前的積累效果就顯示出來了，一開始還是隻有我一個人做前期工作，移植 Wii 版本的 Jade 引擎到 Xbox360。有了信心，就不再驚慌，加上運氣不錯，一個多星期就完成了初步移植。
但總體來說，今後的 2-3 年裡面，沒有突破性的提升，無論是技術上還是管理上：
- 從管理上來說，外企普遍有的玻璃天花板，在 UBI 也存在，中方員工在發展上總是吃點虧。
- 在技術上，沒有機會從頭做一個引擎，總是遺憾。
UBISOFT 是一個很強的技術公司，內部技術相當出色。但對引擎程序員，有一個非常大的限制，就是基本沒有機會從頭參與開發一個引擎。
你的選擇，無法在已有的 Unreal 為代表的商業引擎，或者法國人做出的 Open Space 以及相關各種分支引擎，或者加拿大分公司的一堆引擎裡面選擇。
而當時國內公司，各種自研引擎已經滿天飛，面試招聘的時候經常碰到各路小團隊 CTO、技術指導，表示做過某某引擎，還有人語重心長的勸我，表示做引擎沒啥難的，想做就做一個唄！
大多數此類引擎的水準，大致停留在 10 年前，往往只有渲染部分處在 5 年前的”領先”水準，工具鏈、跨平臺、多人協作等各方面，都沒有看見什麼深入的考慮。
但另一方面，在 UBI 這樣的公司呆久了，不自覺的對從頭做一個引擎有著巨大的恐懼感，公司內部有足夠多的好選擇，必要性不大，而且見過了一流的引擎，龐大的工具鏈，會不由自主高估困難性。
但內心的蠢蠢欲動，還是推動著我，走出下一步。2009 年結束的時候，來到了騰訊。先去各個部門打了一下醬油，瞭解了一下公司，然後參與了天涯明月刀 OL 項目。
對我而言，這個項目是我第一個正規的網遊項目，雖然在前公司也參與過一個網遊項目，但外企在思路轉型上遠遠談不上到位，國內免費遊戲都做了很多年了，外國老闆表示還有免費模式，真能行嗎？
這個項目也是一個好機會，讓我有機會帶團隊真正從頭做一個現代的引擎。
天涯明月刀的引擎和遊戲開發經歷按下不細說，和咱們這個主題不一致。還是圍繞個人成長，展開說說。
一到騰訊的時候就非常緊張，過來的時候 Title 是高級架構師，我有著極其強烈的不能勝任感。
對我來說，有一些領域是全新的，首先在客戶端領域接觸到了國內常用的 Game byro 等引擎，和 UBI 一系技術完全不同，當時也無從判斷究竟 Game byro 之類的引擎是不是代表了先進方向。
其次在服務器領域也是見到了國內常用的技術，在協議處理等角度來看，是相當簡單粗暴的，習慣了歐美一套複雜處理方法，非常不適應。
更大的挑戰在於，以前大量項目都是基於移植或者成熟大型引擎，現在一下子擁有更大的技術發揮自由度，在更簡陋的開發環境中，反而不知道從何做起了。
在這麼多年的個人發展中，總在那些關鍵時刻，有一些不能勝任感，然後奮起直追，讓自己慢慢勝任。
直到前些年在騰訊的經歷，才讓我意識到這適度的焦慮給我帶來的幫助，我也開始更刻意的讓自己常常有一些不能勝任感，以避免自己過於安逸。這個不能勝任感，換另一個說法可能更能被人接受，叫做走出自己的舒適區。
為了緩解焦慮，開始了瘋狂的學習。那兩、三年的閱讀量非常大，每天都有 3-4 小時在看技術資料，做筆記，分析和思考。
先要補上自己的短板，把自己不熟悉的領域熟悉起來。好在孩子還沒有讀書，也有足夠精力，我每天早上提前一個多小時就到單位晨讀，晚上回家還會抽出很多時間閱讀。出差時，晚上或者週末也在酒店閱讀。
幾年的高強度學習，逐漸緩解了我的焦慮，系統的閱讀了大量主題書籍、Gems 類型書籍和會議 PPT 等，大致找到了感覺。可以和別人侃侃而談，不再會在拿出名片的時候臉紅於架構師的 Title 了。
從一個技術指導（Tech director）的角度上，我不需要事事都會做，自有優秀的同事來搞定，我只是偶爾需要在必要時刻，保持一定的突擊能力，可以衝在一線解決困難的問題。
但我必須事事瞭解，知道技術大致的 Tradeoff，知道複雜度，知道和其他系統的關係。換句話說，這個時刻，技術廣度對我來說，比深度更重要。
技術深度的方法可以通過突擊學習，廣度積累當然也可以，但還有其他方法可以做到。
畢竟這時候我也工作了十幾年了，不如剛畢業的時候精力旺盛，孩子也是一個精力黑洞，如何多快好省的培養自己能力，提高效率，變得更重要了。
介紹一些有趣的實踐方法，可以幫助積累技術廣度：
面試學習法
我常年負責遊戲客戶端領域的技術通道面試，技術通道面試可以簡單理解成對面試者定級別的複試。
同時我自己的團隊也招了很多人，面試非常多。從 HR 的反饋來看，被面試的人，表示我面試時候領域知識問得深入，且範圍很廣。
在面試時，面試官有巨大的優勢，面試者的經歷簡單掃一遍後，就可以隨意發問。
我有主動權，可以聲東擊西，選擅長的深入問，不懂的可以簡單帶過，保證不露怯。
也可以長驅直入，對自己感興趣的領域，讓面試者深入講講，聽個大概，成為自己事後瞭解這個領域的入門材料。
可以左右互搏，對於一些面試者的有趣觀點，隨手記下，下次可以問另一個面試者怎麼看這個問題，讓他們的觀點彼此 PK。
可以溫故知新，順便和麵試者討論討論一些主題問題，把平時學習的新技術用上，如果他回答不出來，正好複述一遍，既幫他開拓眼界，也可以加深自己對這個技術的印象。
面試學習法很適合快速拓展知識面，每次面試都是一次技術切磋，如果有機會面試級別高的開發者，更是一個很好的成長經歷。
項目評審學習法
公司內部的項目評審技術評審，也是一個不錯的學習途徑。騰訊的內部遊戲開發，有較完善的流程，除了產品評審環節，也有技術評審環節。
我做了幾年技術評委，通過參加評審，我有機會了解每個項目大致面臨的技術難題，也經常能看見一些閃光點。
比起面試學習法，技術評審接觸的都是公司內部同事，即使有什麼東西當時沒有理解正確，或是過了很久想到這個技術，細節都忘了，也可以找到當時的同事請教。
職級晉升學習法
公司內部對程序員的技術能力升級，有一整套考核，到了一定的職級，就需要有正式的答辯環節。
我常年負責技術評審，申請晉級的同事們會準備自己的工作成果展示，我能看見大量技術問題的分析和解決方案。
和項目評審中的學習有所不同，項目評審時角度更宏觀，具體技術細節不會涉及太多，而自己職級評審中，每個同學都是竭盡所能，從各個角度介紹自己的技術，有問必答，還有事後給面試官送補充說明材料的。
剛參與技術評審的時候，兩天評審中，往往能有 2-3 個技術點讓我眼前一亮。
當然這個學習的衰減速度非常快，前幾年的評審，往往兩天聽完，也沒有什麼有趣的技術點了。
業界會議學習
遊戲圈子比較開放，每年的 GDC 或者其他開發大會，都會有開發者無償公佈很多新的技術，或者總結自己項目的得失，介紹好的實踐。
參與這些會議，是最好的手段，可以快速和國際頂尖水平開發者對齊。你需要的只是一張來回機票，幾天住宿，一張門票和英語聽力。
每次參加完會議，總是特別興奮，有很多好想法想和團隊分享，有很多改進可以做進我們自己的引擎。
如果沒有那麼好的條件可以去現場參加會議，也可以關注會後放出來的免費材料，或是購買付費會員賬號。
上述的學習實踐，本質上就是多聽多看多聊，和其他項目多社交，多聊聊技術，出去多看看其他公司怎麼做項目，堅持做一陣子，自然就有了技術廣度理解。
即使做到了自學成才主攻技術深度，也做到了多社交主攻技術廣度，依然有可能有不足。
群體學習
上面聊到擴展自己的知識廣度，可以通過社交化手段（面試、評審等），或是參加專業會議來達成。
我們的學習方法，還差一個環節。進一步可以做的是群體學習。發動團隊的力量，大家一起來學習，補足自己精力的缺失，也幫助團隊提高能力。
以前在項目組，會做一個每週分享的活動。不管 Senior 還是 Junior，按照姓名排序，輪流來做一個 30 分鐘的分享。
涉及主題可以是新技術，可以是工作中解決的重要問題，可以是外部的有趣技術分享，可以是展會、讀書心得，找自己擅長的就可以。
每週兩個同事分享，佔用整個團隊 1 小時左右，因為團隊人比較多，輪一遍要好幾個月，所以這個活動對聽眾是一個很好的放鬆，也不會對分享人造成非常大的壓力。
做這件事，無論是對個人，還是對團隊，都有很大的意義：
- 擴展廣度：可以充分發揮團隊力量，開拓視野，經常能看見一些讓人眼前一亮，但自己掃描的時候被疏漏的技術點。
- 提高學習質量：逼著大家在閱讀之餘做總結歸納。一個知識如果看完了只是模模糊糊有所瞭解，那麼說明你對它的瞭解還不夠深刻。
如果能總結出來，分享給別人，那你肯定就能深入瞭解它了。最好的學習，就是把這個知識教給別人。
- 鍛鍊表達能力：程序員往往內向不善表達，促進大家分享，也是一個好機會可以教大家怎麼和人溝通，怎麼把知識點更好的表達出來。軟性技能在個人發展的中後期非常重要，但卻往往被人疏忽。
- 促進團隊交流：促進團隊間互相瞭解，比起吃喝類型的團建，這類活動更能讓大家在工作上達成默契。
有時候工作中碰到某個技術，想起前段時間有別的同事分享過，就可以翻出 PPT 再看看，看不懂也可以直接和這位同事溝通，得到進一步的幫助。
- 減少團隊流失：促進學習氛圍建設，也能穩定團隊。遊戲開發總是很忙，如果沒有機會讓大家有所提升，做幾年技術人員很容易荒廢。
看上去很美的團隊學習，實行一段時間以後，也發現了不少問題：
- 能力不匹配：團隊能力和精通領域參差不齊，導致很多話題，一些人聊得津津有味，另一些人完全聽不懂；或是 Senior 對很多初階主題明顯不感興趣，給 Junior 程序員很大的心理壓力。
- 有些員工分享能力實在不行，很好的選題，但講的時候就是平鋪直敘，不考慮目標聽眾的理解。
- 工作進度有壓力，不能一直堅持。輪到某個里程碑版本要衝刺，就很難保證分享活動持續進行了。
- 大家隨意分享，廣度有了，系統性不足。
針對這些問題也可以做一些改進：
- 能力不匹配，可以想辦法通過提前審核選題，來確保題目是多數人感興趣的，也可以通過小範圍組織分享，找更合適的小團隊來群體學習。
- 分享能力不夠，可以通過更多的輔導，幫助串起技術、提煉分享線索、考慮受眾接受度、提前準備逐字稿等方法提高質量。
- 工作進度壓力客觀存在，真堅持不了分享，就暫停一陣子，等忙完再恢復好了，對學習來說，來日方長，不爭朝夕。
- 系統性不足，可以通過組織主題學習的方法，或者有專人掃描某一次會議所有議題，或者一起深入讀一本好書，輪流分享其中章節，或者針對某一技術領域，遍讀相關文章，做全面介紹。
堅持團隊學習大原則的前提下，細節上可以靈活把握，變著花樣，讓大家有新鮮感，養成良好的學習習慣，也能從隊友的進步上有所收穫。
另一個容易被忽視的地方，是整個流程一定要足夠的輕，越輕，越容易推動，太重的流程，容易胎死腹中。
專業領域的積累差不多就聊這些，作為技術總監，還有更多的軟性技能需要鍛鍊。
從技術，走向一線的技術管理，遇到的最大問題是個人效率。而從一線技術管理走向間接的技術管理後，新的問題又湧現。
隨著級別提高，管理範圍的擴大，個人的工作逐漸呈現碎片化和間接化。對事的管理，漸漸變為對人的管理，也給我帶來了很多的困擾。
碎片化是首當其衝的問題。在新的崗位上，業務複雜性大大增加，精力會被極大地碎片化。
大公司的流程本來就複雜，除了項目，還會有各種其他部門和外部公司，為了滿足他們的 KPI，來佔用你”一點點”的時間。
每個團隊真的只會佔用你一點點的時間，但架不住團隊多。這是外部複雜性，如果咬咬牙還能避免困擾，大不了在最忙的時候，就拉下面子全推掉所有的邀約，也能有個清靜。
外部複雜性可以翻臉，但是內部複雜性是無可避免的。做組員的時候，會覺得項目開發是有周期的，有忙有閒，除了最終版本是持續衝刺，其他時候很明顯會有段落節奏感。
但在新的崗位上，再也沒找到過節奏感。我當時主崗不在項目，天涯明月刀項目是兼崗。
往往是項目衝刺的時候一起熬夜，搞完一陣子大家放鬆了，我開始處理主崗的積壓工作，差旅奔波。
組員回血的時候，我在回顧上一階段得失，在制定一下階段規劃，接下來該做什麼，該怎麼做，如何動員內部資源，是不是要引入外部資源協助。組員加班衝刺的時候，也要跟著一起往前跑。
而且大項目，總有這樣那樣的問題，天天忙著救火，這裡消停了，那裡又出問題了，要輪流去關注，經常去支持。
工作中對碎片化問題需要特別警惕。技術學習需要不被打擾的 Unbroken Time 技術管理和決策更需要 Unbroken Time。
但在工作中，技術管理者是很難享受到不被打擾的時間。在開放的辦公環境，人來人往，大家向著你的工位，帶著他的疑問和訴求，希望能分享你的一點點時間，來讓整個項目變得更美好。
你又怎麼忍心拒絕他們，關閉心門？最常見的做法，當然就是割下你的一小片時間，分給你的隊友，換取和諧和共同進步。
悄悄的他走了，正如他悄悄的來
他揮一揮衣袖，留下了一隻猴子（注1）
注 1：[別讓猴子跳回背上(豆瓣)]，有趣的個人效率管理理論，把任務比作猴子，每個人身上都爬滿了猴子，上級要避免把下屬的猴子接過來。
這是一部關於職場陷害和反陷害的書，反映了資本家管理者和白領員工不可調和的結構性矛盾。
但當你的時間支離破碎，你就沒有辦法去做高質量的技術決策，沒時間思考項目方向，沒精力考慮團隊管理。那些才是你更重要的職責，對團隊會產生更長遠的影響。
工作中的幸福程度，和你同時需要關注的事情成反比。
by 某總監
讓我們一起來做些什麼，打響反碎片化的第一槍：
- 帶上筆記本電腦，從工位上消失。寫報告、做 PPT、做規劃的時候，這一招最有效。
相當於你有一個虛擬的會議，這個會議就是你和自己的約定，說好了這次一定要搞定的呢，別給別人打斷你的機會。
- 和大家溝通，說明自己的情況，然後約定溝通的方式和時間段，把同步的溝通變為異步的溝通，小事留言，大事發郵件，天塌下來才可以找我。
當然本質上這是影響其他人效率的，所以適可而止，只在最需要的時候才用這招。
- 每週空出一段固定的時間思考，不約會議，不排任務，身體和靈魂，總要有一個在思考，如果不是兩個都在思考的話。
時間是有彈性的，每次面臨出差或是休假，總能在最後幾天把任務全部 Close 掉，效率會得到提高，同理，如果每週預留出一個時間段給自己來思考，那剩下的時間無疑會更高效。
當然實際沒有那麼理想化，總有這樣那樣的例外，總有不合適的時機。但只要有這個意識，試圖給自己留出一些高質量的思考時間，就會有幫助。
碎片化不可避免帶來了焦慮和壓力。專業能力上我逐漸找到了感覺，但在面對壓力時，還是會恐慌。
本質上來說，壓力來源於目前的能力不足以支撐你的野心。無論是我早期的引擎移植中遇到的專業能力，還是做這個項目遇到的管理壓力，都來自己能力的不足。
治大國若烹小鮮(肉)
by 老子，道德經
沒有太好的手段來解決壓力和焦慮，舉重若輕的自信，來自於更高維度的能力。
對我而言，第一次成功的引擎跨平臺移植後，面對新的類似任務，壓力就小很多。管理過 30 人以上的程序團隊，回頭再管理 10 人團隊，也不會有什麼焦慮。
沒有捷徑可以不焦慮，但有一些簡單的方法緩解焦慮：
- 短期來看，良好的作息習慣。如果天天加班，回家就好好休息吧。別總是覺得公司加班的時間是留給公司的，晚上回家一定要給自己留點時間，熬夜玩一下。沒什麼是晚上早早睡覺不能解決的，如果有，那就再補一個午睡。
- 中期來看，搞點體育鍛煉，據說 XX 能很好改善精力，且有巨大快感。這一點我深表懷疑，因為從我有限的運動經歷來看，每次運動完，我都沒有那種酣暢淋漓的感覺，一般的感覺都是更累了。
考慮到時代在變，白領們裝的方式也在變，現在就是流行說自己愛鍛鍊，鍛鍊包治百病，想來體育運動對緩解焦慮應該也有一定的幫助吧。
- 長期來看，當然就是提高自己的能力，讓自己配得上這個崗位。至於怎麼做，這個系列你都看快看完了，還要問我這個問題？
閱讀更多 51CTO 的文章
