歡迎光臨
每天分享高質量文章

渴望成長的工程師-你瞭解一萬小時定律嗎

導讀:一萬小時定律是指不管你做什麼事情,只要堅持一萬小時,基本上都可以成為該領域的專家。對工程師來說,如何快速成長也是非常受人關註的問題。本文作者對工程師如何在一萬小時之內快速成長給出自己建議。

雷果國,2014 年 11 月加入 nice,負責服務端/前端,擅長 PHP,曾自發翻譯過《Extending and Embedding PHP》一書及 PHP 官方手冊部分模組,2017下半年起探索應用golang。喜歡利用所學構建自己的工具鏈,思考系統和架構設計方面的問題。

前戲

一個月前, 我在和團隊的一位前端同學One On One中, 得知他目前對自己的成長非常困惑, 工作中大量重覆的頁面製作, 沒有太高的技術含量, 業餘時間的學習, 一方面感覺比較零散, 另一方面感覺學來學去, 好像就是那麼點東西.

這位同學剛畢業半年, 自身的主動性是很不錯的, 我就問他平時都學哪些東西. 他提到了ES6, Javascript設計樣式, 以及一些時髦的框架. 以前的聊天中, 我瞭解他閱讀過Javascript高階程式設計, 我就問他在這本書上花了多少時間, 他告訴我花了大概10個小時左右.

我給他列了一份大概的學習計劃, 第一條就是希望他嘗試在Javascript高階程式設計這本書上花費掉500-600小時.(如果掌握好基礎, 那些花哨的技術, 可以很低成本的學習到; 如果不掌握好基礎, 那些花哨的技術, 也只能學習到錶面)

前兩天, 我又和他進行了一次One On One, 他仍然很困惑, 花了4周左右時間, 讀到了Javascript高階程式設計的第5章, 但是感覺仍然沒有獲取到什麼新的知識. 我問了下麵幾個問題:

  1. Javascript中的Number最大值是多少? 為什麼?

  2. Javascript中Number主要有哪些方法?

  3. 為什麼Number要有toString()方法?

  4. toString()方法怎麼實現?

回答大概如下:

  1. 最大值好像是個14位左右的數字

  2. Number的方法列舉了一些, 基本完整

  3. 因為Javascript中所有物件都是繼承自Object.

  4. 這個真沒有想過.

我跟他講了Number是一個double, double應該取找對應的規範取瞭解它的設計, 計算機中儲存的只有二進位制資料, 型別是我們理解資料的依據, 不同的場景需要不同的理解方式, 所以才要有型別轉換. 但並不是儲存在計算機中的一個int, 當做字串讀取, 就能得到它的字串形式. 涉及到字串, 我跟他提了字元編碼的一些基礎, UTF-8編碼規範的一些東西.

他似乎有一些懂我的意圖了.

於是, 我問了最後一個問題, “你是不是在讀書的過程中, 其實是有碰到一些挑戰, 只是把它們給忽略掉了”. 他肯定了我的猜測.

構思

16年年底, 我寫過一篇文章-工程師成長之路:工作1-3年工程師如何突破瓶頸期? 文中, 我主要從軟性素質角度, 分析工程師成長前期, 可能會面臨的一些問題, 以及一些解決的思路.

在碰到上面這個問題之後, 我回想了過去自己的經歷, 以及周圍的同事. 其實, 從事工程師這個職業的同學, 大部分都是有很高的學習熱情的, 尤其在剛工作的那兩三年. 只不過, 後來他們的熱情被逐漸的消磨, 才有了”三十五歲危機”, 才有了我在那篇文章中提到的”可能很多人終生都停留在成熟期”.

是什麼消磨掉了他們的熱情呢? 我覺得至少其中有一部分原因, 和前面這位同學的Case是吻合的. 他們以為自己努力了, 但是甚至都沒有得到自己的認可.(這位同學努力的花費大量精力去閱讀Javascript高階程式設計, 但4周後自己覺得沒有進步)

所以, 我想寫這篇文章, 分享自己在自學提升這條路上的一些經驗心得.

正文

總結我的自學經歷, 我認為有五點是比較重要的:

  1. 一萬小時定律;

  2. 離開舒適區;

  3. 逐層深入;

  4. 成體系學習;

  5. 有效反饋.

一萬小時定律

一萬小時定律, 是中提到的, “1萬小時的錘煉是任何人從平凡變成世界級大師的必要條件。”.

這是一個現成的理論基礎, 但是, 並沒有看到哪個領域因此而量產大師.

因為, 一萬小時意味著, 每天付出3小時專門的訓練, 我們需要堅持10年時間.

正常本科畢業是22歲, 28歲左右就需要考慮成家, 30歲左右該有孩子了. 留給我們的時間非常有限. 所以, 如果你期望在工程技術領域, 有所成, 就應該趁年輕的時候, 最好從大學就開始實踐一萬小時定律.

因為, 越年輕的時候, 能夠自主支配的時間越多.

我們對這幾個階段進行分析:

  1. 大學時代, 平均每天應該就3節大課-6小時, 通勤時間-1.5小時, 吃飯時間1.5小時, 睡眠時間8-10小時. 工作日你每天擁有5-7小時可自由支配時間, 週末為11-13小時. 每年可利用時間為2444 – 3172小時. 刨去正常的社交娛樂, 1500-2000小時非常輕鬆.

  2. 婚前時代, 朝九晚九是正常節奏, 早晨時間太過碎片化, 只有晚上時間可以大塊的自由利用, 凌晨00:00休息是正常節奏. 工作日每天擁有2小時左右可自由支配時間, 週末為12小時左右. 每年可利用時間約為1768小時. 然而你有硬性的社交需求(不然難道和空氣結婚?). 所以, 真正能夠有效利用的時間很難超過1000小時.

  3. 婚後育前時代, 柴米油鹽醬醋茶, 修電修水修馬桶(不然難道讓老王來修?), 無盡的瑣事侵佔你更多的時間, 這個時代, 能夠有效利用到學習的時間, 可能很難超過500小時了.

  4. 育後時代, 有了孩子之後, 你能夠投入到學習提升的時間, 就真的非常非常有限了, 可能每天專註1小時都很難, 尤其是孩子3歲之後, 他需要你的直接陪伴. 週末的大片時間也不用想了, 只要在家, 你就屬於家庭.

做個總賬吧, 大學四年, 你可以輕鬆的擁有8000小時的時間去提高自己, 婚前6年, 可以有6000小時提高自己, 育前2年左右, 大概有1000小時, 育後, 每年應該就只有一兩百小時的樣子了.

所以, 如果你希望有所成, 如果你還年輕, 請慎重的規劃好自己的這15000小時, 這是你最重要最有價值的資本.

離開舒適區

一萬小時定律, 其實也有質疑者.

“家庭主婦每天在做飯上, 投入約為1-2小時. 婚後生活約為40-50年. 所以, 家庭主婦在做飯上投入的時間大概有小兩萬小時. 但是, 他們並沒有成為大師.”

所以, 一萬小時定律也有額外的限定條件, 其中一條, 就是”長期處於學習區學習”.

“學習區”是一個美國人提出的概念, 人們要學習的事物, 可以分為三個等級:

  • 舒適區: 沒有學習難度, 習以為常, 自己可以處於心理舒適狀態;

  • 學習區: 對於自己有一定挑戰, 因而心理感到不適, 但不至於太難受;

  • 恐慌區: 超出自己能力範疇太多, 因而心理嚴重不適, 導致崩潰並放棄學習.

家庭主婦的例子, 只是在重覆相同的工作(舒適區), 所以不能成為美食領域的專家. 而在文首提到的例子中, 那位同學最後也認可我的猜測, 他在看書的過程中, 其實原本是有挑戰的, 只是被忽略掉了.

其實, 這很常見, 當我們碰到有挑戰的問題時, 總是希望用最短路徑解決它. 這是人類的本能. 當碰到有挑戰的問題時, 伴隨著心理的不適, 我們本能的就希望儘快的擺脫這種狀態.

而對於學習來說, 那個小的挑戰帶來的收益是很難評估的, 而忽略掉它其實並沒有什麼成本. 自然而然的, 我們就會選擇放棄了. 當一個又一個小的挑戰被放棄之後, 逐漸形成了習慣, 以至於, 每次學習, 好像並不能獲得新的知識.

所以, 在學習的過程中, 我們需要刻意的訓練自己, 讓自己的潛意識, 就能夠剋服放棄挑戰的本能.

逐層深入

這一點, 與”離開舒適區”息息相關. 我們的目的, 其實是進入”學習區”, “離開舒適區”只是一個步驟.

下一步, 就是要避免進入恐慌區.

前面提到我在正則運算式的學習上, 花費過超過200小時, 這200小時是怎麼花費的呢?

  1. 2008年學習J2SE時, 碰到正則運算式, 第一次學習, 理解它是一個和萬用字元類似, 但是更牛逼的東西

  2. 2009年, 學習中, 經常碰到正則運算式, 就又專門透過Java的正則運算式檔案學習了一遍.

  3. 2010年, 學習javascript/python分別碰到正則運算式, 兩次學習, python的正則運算式檔案進行了系統的學習, 對正則運算式中的一些高階特性有了比較清晰的認知.

  4. 這個階段, 有一個問題一直困擾我, “如何用正則運算式完成Html標簽的匹配識別, 允許屬性單引號或雙引號, 允許引號內有跳脫字元”.

  5. 2011年, 翻譯php的pcre模組檔案時, 進行了更深入的學習, 大概半年後, 我終於寫出了上面困惑自己兩年的正則運算式. (當時還寫過部落格分享[1])

  6. 2013年, 閱讀第一章, 理解了正則運算式匹配引擎的實現原理.

  7. 後來, 零零散散的閱讀了一書.

  8. 2014年, 閱讀了Nginx中配置檔案解析的過程.

  9. 2016年, 閱讀了php程式碼的解釋執行過程.

再後來, 就是現在了, 在這個方向上, 我仍然有想要解決的問題, “學習編譯原理, 能夠掌握一種編譯工具, 可以讓自己更自由的描述規則”.

這是一個循序漸進的過程, 我認為這不單純的是正則運算式的學習, 而是在逐步加深對字串處理的理解. 從最開始只能粗淺的使用正則, 到後來理解它的原理, 再逐步涉及到到編譯體系的邊緣.

如果一開始, 我面臨的就是”解析HTML標簽”這樣的問題, 那估計我早就被乾迷惑了. 而這種循序漸進, 逐層深入的方式, 在不斷讓我進步的同時, 一次又一次激勵讓我產生更高的興趣.

所以, 當你進行一項技術學習的時候, 也請仔細的拿捏, 到底哪裡才是自己的學習區, 離開舒適區, 也不要進入恐慌區.

成體系學習

前面算過了, 從大學時代開始, 到你沒有精力可用之前, 你一共有大約15000小時的資本.

這15000小時的使用, 應該需要你慎重的考慮, 當做一種投資去做這件事.

我到現在為止, 花在程式設計這件事上的時間, 應該在7000小時左右. 時間分配大致如下:

  • 最初學習的是Java體系的東西, J2SE, J2EE, 三大框架等等這些東西, 我大概花費了3000小時

  • 花費在學習其他語言上的時間, 總計大概有2000小時左右(python, javascript, html/css, php及其核心, c, bash, golang, erlang等).

  • 學習作業系統相關知識, 大概耗費了500小時

  • 學習計算機網路大概耗費了500小時

  • 閱讀開源軟體原始碼, 大概花費了500小時(jQuery/jQueryUI, Memcached, PHP, Nginx等).

  • 學習資料結構與演演算法, 大概耗費了200小時

  • 學習正則運算式, 大概花費了200小時

按照我投入的7000小時來看, 應該至少接近大師了吧, 然並卵.

我覺得這是我的投資失誤. 我在Java體系和其他語言的學習上, 花費了5000小時. 但是, 在作業系統/網路/體系結構/資料結構與演演算法等核心基礎方面, 投入的精力太少. 這些基礎的相對薄弱, 就導致我現在做一些事情心有餘力不足.

所以, 在你下定決心, 在學習區度過10000小時時, 請一定規劃並經常Review自己學習的體系.

如果能夠從頭再來, 我會這麼做這份投資:

  1. 2000小時, 精通一門語言, 理清這門語言生態下週邊技術的脈絡.

  2. 500小時, 基礎的資料結構與演演算法.

  3. 1000小時, 理解計算機體系結構.

  4. 1000小時, 理解作業系統的運轉.

  5. 1000小時, 理解計算機網路.

  6. 2000小時, 閱讀開源軟體原始碼.

  7. 2000小時, 架構領域的學習與實踐.

  8. 500小時, 涉獵其他語言或領域, 擴充套件知識面.

當然, 青春一去不返, 空悲切.

有效反饋

關於一萬小時定律, 有兩個限定條件, 其一是上面提到的”長期處於學習區學習”, 另外一條, 就是”有效反饋”.

有效反饋的意義, 我覺得主要有三點: 1) 激勵並培養更高的興趣; 2) 修正不足; 3) 調整學習區.

第一點, 其實是建立對自己的心理暗示, 讓自己持續的保持對所做事情的高度興趣. 這一點, 不僅可以透過學習過程的正向結果來激勵, 也可以透過其他方式來培養. 比如, 刻意的培養, 讓自己更多的在興奮狀態下寫程式碼, 身體形成習慣之後, 你就更容易在寫程式碼時處於興奮狀態, 有更加積極的思考.

第二點, 以學習正則運算式為例, 學習了正則運算式的一條規則之後, 應該嘗試用大量的實體去測試, 驗證自己的理解是否正確, 每一個無法透過的case, 可能正好能為你帶來新的知識.

第三點, 前面提到處於學習區非常重要, 有效反饋是調整學習區一個非常重要的途徑. 當你在目前的學習中, 已經無法得到負向的有效反饋, 那就代表當前已經處於舒適區了, 應該儘快調整.

不過, 當你判斷自己在某個方向已經處於舒適區時, 可能很難直接找到這個方向的下一個學習區. 此時, 建議換一個明確自己處於學習區的方向進行學習. 在你整體學習體系之下, 不同方向的知識應該是相輔相成的. 這就像盤山公路的S形設計一樣, 即可以看到每個方向的風景, 緩解視覺(心理)疲勞, 又在不知不覺間, 用一種省力的方式, 攀至高峰.

總結

本文的核心觀點, 就是一句話: 有效規劃自己的時間, 透過有效反饋, 讓自己持續一萬小時處於學習區學習成長.

我是幾乎從零基礎自學成長的, 成長過程中, 受到無數散佈在網路上, 由陌生人釋出的資訊的幫助. 雖然最終沒有大成, 但我也渴望能夠幫助別人成長, 成為開源共享傳承中的一個節點.

所以, 如果你認為這篇文章對你身邊的朋友, 能夠有所幫助, 請轉發給需要的人.

nice是一家很酷的移動網際網路公司,我們正在招聘後端工程師、Android工程師、iOS工程師、高階運維工程師、高階演演算法工程師、大資料高階工程師,相中nice可以發簡歷到(leiguoguo@oneniceapp.com)。

資料連結

[1] http://blog.csdn.net/lgg201/article/details/7107228


高可用架構

改變網際網路的構建方式

長按二維碼 關註「高可用架構」公眾號

贊(0)

分享創造快樂