多做項目
我是半路出家的，頭髮沒剃光的那種（實際上我現在頭髮還茂盛得很）。我在培訓機構呆了半年就出去找工作。
第一份工作失敗了——底子太薄，工作擼不動，很快主動辭職了（怕被請辭就太沒面子了）。
然後我花了點時間惡補了下——用今天的眼光看，那時的底子仍然薄得可憐，不過能應付初級工作。
第二份工作，我獨立做了很多項目——對於菜鳥來說，能有獨立項目做很重要，它能讓你較早地思考設計問題，而不僅僅是 CRUD。初入編程行業，最怕的就是幹了幾年，除了 CRUD 啥都不會，這對後面的發展非常不利。
然而現實的悖論是，菜鳥一般很難接到獨立項目（特別是對性能、穩定性有些要求的）。換你做 Leader，你會把重要的工作分給哪隻鳥？
所以菜鳥一定要有主動工作的意識。要有想法，且樂意表達自己的想法。開會的時候多發言，多說說自己的想法（但要謙虛，不要爭吵，千萬不能讓人覺得自己自負、不合羣）。要想讓 Leader 能分配重要任務給你，首先要獲得他的信任，要讓他覺得你是個潛力股，值得培養。
有一個很重要但被很多人忽略（或不屑）的點：要自己找事做。你得學會沒事找事。在我的職業生涯中，對我提升很大的項目中有一半都是我自己找的。我說的項目不是項目管理那個意義上的項目，它可以是需求，也可以是系統優化，可以大到需要多個團隊協作，也可以小到僅僅是個通用組件開發。
當然不是瞎找。要找公司的產品和系統有什麼痛點，這些痛點你能不能解決，解決了對你和公司能帶來什麼好處——雙贏纔是唯一的出路。
我發現公司的登錄流程混亂不堪，經常要接入分支流程，於是提出重構登錄模塊；我發現公司各系統的下載功能都是各自開發，而且數據量一大就崩潰，於是提出開發統一的下載中心；我發現公司各種管理後臺系統日益增加，系統間沒有一個統一登錄方案，便利用加班時間開發了個 sso 系統。我還自己寫框架，然後在公司內推廣讓別人用......
我像一隻地鼠到處鑽，還自己造輪子——世界上有那麼多輪子，一個重要的原因是造輪子本身是團隊和個人技術沉澱的有效手段。我通過開發框架理解了大部分的設計模式。
所以，如果初出茅廬，看多少經典書籍不是主要的，主要的是要多做項目，特別是有挑戰的項目。不要怕失敗，我有很多項目是失敗的（有些功能優化被證明比優化前更糟；有些項目壓根沒上線），那又怎樣——至少我思考過，實踐過。
多看書
一味地做項目並不能大幅提升自己。編程能力跟做項目的數量沒有必然關係——雖然在接觸不同的釘子，但你手上拿的還是原來那把錘子。
有些人以自己“動手能力強”爲藉口鄙視看書。他們信奉“實踐出真知”，看書無用（特別是理論性較強的）。
熟不知書籍本身就是前人的經驗總結，還是牛人的經驗，所以必須看，看多少都不爲過。
之所以是先多做項目後海量看書，是因爲在沒有一定的實戰經驗之前，很多書你是看不明白的。
其實這個順序並不精確，往往是同步進行，但不同時期側重點不同。
起初一般看工具型的，如各種“深入理解”系列（深入理解 MySQL、深入理解 Redis），加深工作中密切相關的工具（你具體使用的編程語言、數據庫、緩存都是工具，這裏不是說編程語言 IDE、MySQL 客戶端這種開發工具），稍微深入到其底層細節——但除非你對某個東西特別感興趣，否則此階段沒必要過於深入，沒必要每個工具都要研究到源碼級別，燒腦是一回事，人的時間是有限的。
研究完這些工具，你會發現過去項目中一些代碼實現、數據庫設計是有問題的，存在優化空間的——這說明書沒白看，能力提升了。能力提升的標誌是能意識到之前的實現方式的不足和改進點。
接着需要多看看跟具體工具無關的書，像計算機原理、操作系統、設計模式、系統架構、算法，甚至軟件工程。如果說前一個階段的閱讀重心是搞清楚如何用 Redis 做緩存系統，這個階段則是學習系統架構中的緩存實踐模式。
這種類型的書籍重點是講思想和實踐經驗，所以多少有點抽象，很多書看一遍後雲裏霧裏，覺得好像學到了什麼，但又什麼也沒學到。這很正常，因爲你的項目實戰經驗還不足以支撐自己去深入理解這些東西。
我在看《領域驅動設計》時，雖然處處都能感受到驚喜，但很多概念是囫圇吞棗，覺得自己理解了，又好像沒理解。像聚合、聚合根、限界上下文、領域服務、應用服務，低頭看書時覺得上面的東西都能看得懂，一旦擡頭思考就卡住了。這一方面反映出我經驗不足，另外也說明我正觸碰到自己的認知邊界，正在接受一種全新的知識或說認知模式——一旦得到突破，便會有質的提升。
看完《領域驅動設計》後的一個重要效果是，以後在設計系統時，我會有意識地去用 DDD 裏面的東西思考設計。這時候多半會卡殼——經常卡的那種。於是我會回頭再去看書，因爲這時候是帶着問題看的，直接找到相關主題看一遍，多半會有“原來如此”的感嘆。
比如一些控制器裏面代碼邏輯較多，而且很可能多個控制器存在相同或相似的邏輯，但這些邏輯又明顯不屬於領域層，怎麼辦呢？我忽然想到應用服務的概念，這些邏輯應該抽離成服務，但屬於應用層的服務。這樣一實踐，大致就理解了原本抽象的概念。任何概念都是用來解決問題的，如果你不知道一個概念是用來解決什麼問題的，你就沒有理解這個概念。
所以做項目和看書是不斷迭代的過程，不斷學習，不斷實踐，不斷思考，你才能不斷突破自己。
學習是辛苦的，突破是痛苦的。人的大腦本能地喜歡呆在舒適區。我們今天學了這門語言，明天再去學那門語言就會覺得很輕鬆，因爲兩門語言的學習模式是一樣的，大腦是呆在舒適區的。但今天學習這門語言，明天去學習這門語言的實現就會很痛苦，因爲這是兩種不同的認知模式，大腦需要走出舒適區，一旦走出舒適區就會進入混沌態——大腦不喜歡混沌態。
要想獲得大的突破，必須學會接納處於混沌態的自己。
讀些歷史書。這不是必須的，但“讀史使人明智”是真的。感興趣的話讀一讀人類歷史（不是教科書那種），以及科技史。至少要讀讀計算機史。歷史能告訴我們一些東西爲啥是這樣而不是那樣的。計算機爲啥叫 Computer？一個字節爲啥是 8 比特？鍵盤爲啥是 QWERTY 佈局？計算機一開始就用的二進制嗎？爲啥說馮·諾依曼是現代計算機之父？學史跟編程沒有必然關係，但能開拓你的視野，讓你知道那個時候人們面臨怎樣的問題，是怎麼解決的。有些你認爲的新東西其實很早就被髮明或構思出來了（比如 10 年前開始流行的雲服務概念其實在上個世紀 60 年代就以“計算機公用設施”的概念盛極一時）。
人們不喜歡看書的一大理由是一種人人都有的感覺：很多書看完後很多東西都不記得了。這種感覺很不好。
有句話叫“好讀書，不求甚解”。我對“甚解”的理解是企圖把書中每個知識點甚至每句話都搞清楚並記住。
沒那個必要。除非記憶力超羣（據說馮·諾依曼就有這個能力），大部分人在讀完一本書後都會忘掉大部分內容（甚至讀得越慢忘得越多）。但今後你再去讀任何一個章節，你都會覺得很熟悉，有時候在項目實踐中大腦會突然蹦出個原本已經“忘記”的知識點。這是大腦的正常生理機制，沒必要跟它較勁。
我有時候讀完一本書後，大腦裏只剩下一個概念，其他的一概忘記了。比如我讀完《設計原本》後，腦袋裏只剩下“概念完整性”這個詞。也許當時我真的沒讀懂這本書，但光這個詞就讓我獲益匪淺。在日後的系統設計、團隊管理，特別是跨團隊協作開發中大型系統時，這個詞不斷地出現在我腦海中。很多系統上線後 bug 不斷，就是概念完整性（以及概念一致性）上出了問題，比如多個系統對同一個概念定義不同；金額四捨五入規則不同；一些重要概念在系統設計之初缺失（或誤用）導致系統設計上的重大缺陷；對某些概念未做澄清而導致實現和預期不一致（如什麼是“用戶”，什麼是“會員”）。項目啓動之初需要花大量時間和精力來達成概念完整性和一致性（各種會議、宣講，各種設計文檔），很多項目缺少了這些步驟導致後期混亂不堪，團隊中每個人都只見樹木不見森林。
所以，若能從一本書 get 到一個讓自己終身受用的東西，夫復何求？
放一張鄙人的讀書清單鎮樓（讀沒讀完不要緊，架勢要擺出來）：
多擼源碼
一個人能做的項目是有限的，而且很多項目都是同一種類型。更有甚，由於各種原因（如進的公司只有 CRUD 型需求）壓根沒機會承接稍有挑戰性的項目鍛鍊自己。咋辦？
既然自己沒項目擼，就去擼別人的吧。
有很多高質量的開源項目，擼起來津津有味。很多時候，擼完一個高質量（但不一定規模得有多大）的開源項目比自己開發一個項目收穫要大得多。
你看書時存在的疑惑很多都能在擼源碼的過程中找到答案。我相信你初學設計模式時一定跟我一樣自認爲懂了，又覺得沒懂，反正感覺很抽象。擼些源碼，你會發現裏面用了很多設計模式，你會感嘆“哦，原來這樣用”。
擼源碼之前最好看下對應項目的手冊，使用下，有個整體瞭解。也可以百度找下其他人擼出來的筆記，瞭解下大致的技術結構。
先擼簡單的。走上來就擼 nginx，很容易留下心理陰影，從此戒擼。我學 golang 的時候就是從一個很簡單的緩存中間件（幾千行代碼）開始擼，越擼越有信心。
要寫筆記。我喜歡直接從 github fork 過來，邊擼邊寫註釋。
如果真的不想擼，或者擼不動（被裏面各種彎彎腸子的設計繞得雲裏霧裏），也可以看別人擼。可以花點錢在極客時間上看大神們擼。
有些項目擼着擼着就變成自己的項目了——我的意思是面試的時候可以寫入簡歷裏面，和麪試官聊的時候可以說說你對那個項目的理解，甚至能撒個謊說自己開發過類似的項目（別說我教的）。
去帶團隊
程序員經常問的一個問題是：做開發到後面必須要帶團隊嗎？
這個問題我也不知道答案（很多帶“必須”字眼的我都不知道答案——怎麼回答呢？說必須？肯定有人反駁；說不一定？感覺像個教科書），所以不打算回答。
我想說的是，如果你有帶團隊的機會，就去把握——特別是比較完整的團隊（不是整個公司就一個前端一個後端這種）。至少要去試試。
不是說帶團隊未來就一定是走管理崗，不敲代碼了。帶團隊對自己的實力提升有很多好處，我們不說提升什麼綜合能力，單說資源。
職位越高，可以擁有的資源就越多。當你只是普通的開發人員時，多數時候你只能被動接受別人的任務安排，哪怕這個任務對提升能力沒什麼幫助。但當你成爲組長、經理、總監、CTO 時，你會發現自己能決定的事情越來越多（當然責任也越來越大），能夠影響的範圍越來越大，能夠獲得的資源越來越多。
這不是說你一定要走這條路，只是說要有這個意識——畢竟國內大部分公司資源是通過“帶團隊”的形式獲得的。
如果我鐵定了走技術路線，資源有什麼用呢？可能沒用，比如你在某個真的靠技術論天下的大廠當資深程序員。但只要你想往架構師方向發展（首架被普遍認爲是技術路線的目標），你會發現你其實非常需要資源（當然成長爲架構師並不是非要帶團隊不可）。
我們不提什麼架構師，就說普通程序員崗。所謂資源，是指爲做某件事所需要的人力、財力以及時間。比如你想開發個系統，或者做個重構（從成長的角度來說對你以及團隊都有好處），如果你有一定的影響力（或者權利），你就有可能說服你的上司同意你做這件事（可能要兩個月時間，並涉及到幾個團隊的人事協作）；更有甚，你可以自己決定做不做這件事情。
起碼，你能成爲一個團隊或一個項目的技術負責人，這並不難。站在團隊 Leader 的角度，也能讓你的視野更加寬闊。
當然，如果你對帶團隊很反感（請確認並非你的大腦不想走出舒適區），你完全可以不帶。這裏是說帶團隊可以獲得資源，但不是說資源只能通過帶團隊的方式獲得。
多寫東西
大神都有一個共性：喜歡寫博客。
上學的時候，學習好的大多喜歡記筆記，有些老師還強制要求學生記筆記。寫東西能強化記憶，還能加深對知識的理解。
寫作有益於構建一個人的知識體系。比如你對 DNS 有個初步瞭解，大致知道它的作用是將域名解析成 IP 地址——僅此而已。但如果你打算寫一篇關於 DNS 的文章，肯定不能僅此而已。你會去查資料，瞭解 DNS 的歷史，研究現實中 DNS 解析的具體實現方式。這過程中，你瞭解到全球 DNS 層次結構，最上面有根 DNS 服務器，下面有頂級域服務器，再下面有權威 DNS 服務器；你瞭解到 IANA 和 ICAAN 的歷史，順便還了解到 IP 地址在全球是怎麼統一管理的；你還了解到如何通過智能 DNS 解析實現 CDN 網絡；甚至你想自己搭建個權威 DNS 服務器。如果不寫博客，你很難有動力去了解這些，很難構建出 IP 和域名的完整知識體系。
對我而言，寫作還有個好處是刺激思考，整理思路。有時候我面對一個問題半天沒有頭緒，於是我嘗試把問題作爲文章標題大大地寫下來。第一步，我嘗試寫出來關於該問題我能想到的任何東西（對問題本身概念性的釐清、初步的推理、引申出來的新問題等等，只要能想得出來就寫下來）——然後我會發現自己的思路像是開了閘，自此暢通無阻。寫作能鍛鍊人的思維能力。
從長遠看，寫作能建立個人品牌。公司需要品牌，個人也是如此。建立個人品牌（或叫打造個人 IP）主要有三種途徑：
- 混大廠。加入頭部公司（如 BAT）並在裏面混個不錯的名頭；
- 混開源。開發一款高 star 的開源軟件或作爲某款知名軟件的重要貢獻者；
- 寫博客。
有些大牛三方面都佔了，但如果你我做不到這點，可以嘗試只做一項，比如寫博客。
很多人“不善於”寫作。這是藉口。沒有人天生就善於寫作。那些所謂“善於”寫作的都是長時間訓練出來的。另外，寫技術博客並不需要你的寫作功底多麼好——話能說明白就行。
還有些人覺得自己現在技術不咋地，怕班門弄斧，覺得還是等底子厚了再寫。沒必要，因爲寫博客本身就是提升技術底子的非常快速有效的手段，不要顛倒了。如果有人看你的博客更好（有人看是大部分人能持續寫作的主要動力），沒人看的話，權當自我提升，順便練練手，寫得多了積累得多了質量自然上來了，自然會有人看了。
還有人覺得自己想寫的別人已經寫了很多了，沒必要再重複這些事情了。已經有那麼多小說了，仍然有人在寫；已經有那麼多音樂了，仍然有人在譜；已經有那麼多輪子了，仍然有人在造。從某方面看，《聖經》說得沒錯：太陽底下，並無新事。但另一種說法是一千個觀衆就有一千個哈姆雷特。每個人對同一個問題的看法，對同一個知識的理解都是不同的，雖然 HTTP 協議已經被講爛了，但你的理解，你的寫作風格，或許會有些新意。就算全無新意，一樣會有人看，因爲信息不是同步的，總有人會來到你的地盤而不是別人的。
所以，不要想得太多，寫就是了。
關於寫作平臺，真是太多了：博客園、CSDN、知乎、簡書、掘金以及自建博客等等。還有人喜歡用 github（不過對搜索引擎不太友好，所以個人不太建議）。
個人比較喜歡博客園，我覺得博客園技術氛圍最濃厚，也最簡潔，沒那麼多幺蛾子。當然，如果你打算將寫作事業長久經營下去，不妨嘗試去經營自己的公衆號，雖然更難，但一旦你堅持住了，從長遠看，它會給你帶來更大的收益（成長、品牌以及資金收益）。
去當講師
一般互聯網公司都有技術分享會，但我發現很多人不願意去抓這種機會。有些團隊的分享會進行不下去，不得不給成員分配分享任務，而大多數人也是將其作爲一種額外負擔看待的，甚至有人抱怨 Leader 給自己加了額外的任務導致自己不得不加班。
無論你處於什麼級別，能成爲任何分享會的講師都是莫大的機會，值得去把握。大牛們都十分樂意參加各種分享會，公司內部分享會，行業峯會等等。
當講師至少有三方面的收益。
首先，快速提升專業能力。和寫作一樣，你必須選擇一個主題，該主題可能是你非常熟悉的，但更多時候可能只是粗略瞭解過。所以你必須網羅材料並整理成體系。比如你想講 Unicode，因爲你先前大致瞭解過這塊，還自己寫過 UTF-8 的實現 demo，覺得對這塊很在行。但當你規劃講稿結構時發現，必須要先講講 Unicode 出現之前的字符編碼情況，據此才能引出 Unicode 的歷史必要性。於是你瞭解到 ASCII、ISO-8859、GB 2312、Big5 以及 IBM 和微軟的各種代碼頁；而後 Unicode 出現了，你必須搞清楚的一件事是，Unicode 如何兼容這些早期的字符集編碼，於是你不得不深入 Unicode 的實現細節；當你瞭解到原來早期 Unicode 採用的是雙字節定長編碼方案時，你必須去探明爲何後面 UTF-8 超越 UTF-16 成爲應用最廣泛的 Unicode 實現方案？如此，當你準備完講稿時，你已經構建了自己的字符集編碼知識體系（而不僅僅是瞭解些 Unicode 和 UTF-8 的零星的知識）。
其次，鍛鍊自己站臺講話的能力。隨着經驗的積累，職位的提升，你多少需要上臺講點話。你無需做到口若懸河，但最好也不要語無倫次。程序員平時很少有這種上臺講話的機會（機會出現了大部分人也不願意去抓）。當講師一方面氛圍比較輕鬆，除非是大公司幾百甚至幾千人的分享或者行業峯會，否則聽衆基本都是平時打交道的熟人，你不會有多大心理壓力（特別是做過幾次分享後）；另外你要講的內容是充分打好草稿（PPT）的，心裏有數。所以這種場合的演講大部分人都能駕馭得了。但分享也是演講，要講究演講技巧，要將聽衆帶入你的世界並很容易理解你所講的東西（很多人做技術分享就是在那裏讀 PPT，完全不考慮聽衆感受，搞到後面很多人都在那玩手機了）。這是讓你體驗演講並鍛鍊演講技巧的大好機會，大部分人第一次都講不好，但多講幾次，就會不自覺地去思考並提高演講技巧。
最後，讓更多人認識你。你是不是認爲大家都在一個屋檐下共事，還有誰不認識你的？除非你在公司技術圈有很大影響力（大家公認的大牛），否則不認識你的人多了去了。所謂認識，不是說人家知道你名字就完事了。所謂認識，是要人家知道你在做什麼，你擅長做什麼，你哪方面比較牛；進而，認識會轉化爲“認可”：讓別人認可你，更讓你的 Leader 認可你。今後有機會參加行業峯會了，也是讓更多的業內人士認識並認可你——如此也就打造出你自己的 IP 了。
很多人不願意當講師，除了沒有上臺演講的經驗外，一大顧慮是認爲自己並沒有什麼特別擅長的東西。記住一點，多數時候，不是因爲你真的擅長某方面纔去分享，而是你先決定分享某個你熟悉但不精通的東西，然後去鑽研，在分享的同時也真正精通了這個主題。
如果一開始沒有信心，就從小範圍做起。從小組內部分享開始，內容也不用那麼專業那麼深入，隨意點。然後擴展到部門或者公司層面。
做分享跟寫博客一樣，於人於己都百利而無一害，不要等，儘早去做。
不是因爲自己行纔去做，而是先做了纔行的。