讀程序員的README筆記01_學習如何學習.png

1. 核心領域中所需要的能力

1.1. 技術知識

1.1.1. 技術知識

1.2. 執(zhí)行力

1.2.1. 過用代碼解決問題來創(chuàng)造價值，并且你了解你的工作和業(yè)務之間的聯(lián)系

1.3. 溝通能力

1.3.1. 能同時以書面和口頭的形式進行清晰的溝通

1.3.2. 能以建設性的方式提出問題和定義課題

1.3.3. 文檔化你的工作

1.3.4. 撰寫清晰的設計文檔并征求反饋意見

1.3.5. 與他人打交道時，你富有耐心和同理心

1.4. 領導力

1.4.1. 能在指定的工作范圍內(nèi)獨立地完成工作

1.4.2. 能迅速地從錯誤中學習

1.4.3. 能很好地處理變動和模糊的問題

1.4.4. 積極參與到項目和季度的規(guī)劃中

1.4.5. 能幫助新的成員融入團隊

1.4.6. 可以向你的管理者提供有意義的反饋

2. 能力的4個階段

2.1. “無意識的無能力”

2.1.1. unconscious incompetence

2.1.2. 意味著你無法勝任某項任務，并且沒有意識到這種差距

2.2. “有意識的無能力”

2.2.1. conscious incompetence

2.2.2. 意味著你雖然無法勝任某項任務，但其實已經(jīng)意識到了其中的差距

2.3. “有意識的有能力”

2.3.1. conscious competence

2.3.2. 意味著你有能力通過努力完成某項任務

2.4. “無意識的有能力”

2.4.1. unconscious competence

2.4.2. 意味著你可以很輕松地勝任某項任務

3. 坎寧安定律

3.1. 定律認為：在互聯(lián)網(wǎng)上獲得正確答案的最好方法并不是提出問題，而是發(fā)布錯誤的答案。

3.2. 建議你在團隊中用文檔記錄下會議的內(nèi)容、入職流程和其他口口相傳的東西

3.3. 重點并不是要寫一份完美的文檔，而是要寫得足夠多，以引發(fā)討論，充實細節(jié)

4. “自行車棚”(bike-shedding)效應

4.1. 過度集中在細枝末節(jié)上的討論總是會很冗長，這種現(xiàn)象被稱為“自行車棚”(bike-shedding)效應

4.2. 是西里爾·諾思科特·帕金森的一則寓言故事

4.3. 該寓言描述了一個被指派到發(fā)電廠對該發(fā)電廠的設計方案進行評審的委員會的故事

4.4. 對該委員會來說，因為發(fā)電廠的設計方案過于復雜，以至于無法討論出什么實際的內(nèi)容，所以他們花了幾分鐘就批準了這些計劃

4.5. 他們又花了45分鐘來討論發(fā)電廠旁邊的自行車棚的材料問題

5. 試煉

5.1. 大多數(shù)新入行的工程師在開始時都有技術基礎，但沒有什么實質(zhì)上的經(jīng)驗

5.2. 在你的成長過程中，持續(xù)學習是至關重要的

5.3. 多報名參加技術講座、午餐會、閱讀小組、導師計劃

5.4. 你著手開發(fā)大一些的任務和特性就意味著你進入了“貢獻者之角”

5.4.1. 團隊會信任你能更獨立地完成工作

5.4.2. 參與到代碼評審中去，做好隊友會詢問你的想法和反饋的準備

5.5. 當你參與到更大的任務中時，你將會學到如何向客戶交付代碼

5.5.1. 當你參與到更大的任務中時，你將會學到如何向客戶交付代碼

5.5.2. 你需要使用監(jiān)控指標、日志和跟蹤工具來實時調(diào)試軟件

5.5.3. 你也可能需要參與輪流的On-Call

5.6. 你的團隊現(xiàn)在將依靠你來負責一個小項目

5.6.1. 需要撰寫一份技術設計文檔并幫助團隊進行項目規(guī)劃

6. 學習如何學習

6.1. 自覺階段

6.1.1. 校外學習是一種技能

6.1.2. 萬事都求人”和“獨行俠”之間取得平衡

6.2. 學習將幫助你成為一名合格的工程師，并在未來的日子里持續(xù)進步

6.2.1. 如果你不學習，你就會落后。

6.3. 前置學習并不意味著要整天坐在那里閱讀文檔

6.3.1. 在實踐中學到的東西要比只坐在那里單純地閱讀學到的多出許多

6.3.2. 你應該上手編寫并且發(fā)布代碼

6.3.2.1. 錯誤是不可避免的。成為一名軟件工程師的路途艱辛，我們有時會失敗

6.4. 運行實例代碼可以真正地了解代碼的工作原理

6.4.1. 調(diào)試器是你運行實例代碼時最好的朋友

6.4.2. 可以用它來暫停正在運行的代碼，然后查看運行中的線程、堆棧信息和變量的實際值

6.4.3. “謎之行為”通常都是由正在被調(diào)用的程序是舊版且你修改的內(nèi)容沒有生效造成的

6.5. 請每周都花一部分時間去閱讀

6.5.1. 團隊文檔

6.5.2. 設計文檔

6.5.3. 請從團隊文檔和設計文檔入手

6.5.4. 代碼

6.5.4.1. 代碼從不說謊。注釋有時卻會。

6.5.4.1.1. Code never lies. Comments sometimes do

6.5.4.1.2. 去讀源代碼，因為它并不總是與設計文檔相吻合

6.5.4.1.3. 不要只讀你自己的代碼庫，還要去閱讀高質(zhì)量的開源項目，特別是那些你使用的類庫

6.5.4.1.4. 請利用你的IDE來瀏覽代碼

6.5.4.1.5. 為關鍵的操作繪制控制流和狀態(tài)圖。仔細研究代碼的數(shù)據(jù)結構和算法

6.5.4.1.6. 留意那些慣用寫法和風格，也就是去學習“本地方言”(local dialect)

6.5.5. 積壓的任務票

6.5.5.1. 舊的任務票大概分為三大類

6.5.5.1.1. 不再相關的

6.5.5.1.2. 有用但次要的

6.5.5.1.3. 過于重大且無法立刻解決的

6.5.6. 論文

6.5.7. 書籍

6.5.8. 技術網(wǎng)站

6.5.9. 出版物和在線資源是互補關系

6.5.9.1. 出版物大多很可靠，只是有些過時

6.5.9.2. 在線資源則正好相反，不那么可靠，但很能跟上潮流

6.5.9.3. 采用保守一些的技術選型是有益處的

6.5.10. 這些文檔會就事情是如何組合在一起的給你一個整體的概念

6.5.10.1. 不要試圖一下子把所有東西都讀完

6.6. 觀看講座

6.6.1. 可以用1.5倍速甚至2倍速觀看視頻，以節(jié)省時間，但不要被動地觀看

6.7. 適度地參加會議和聚會

6.7.1. 會議和聚會非常有利于建立聯(lián)系和發(fā)現(xiàn)新的想法

6.7.2. 那些有價值的內(nèi)容與所有內(nèi)容的比例——也就是信噪比，通常都很低

6.7.3. 學術會議有很棒的內(nèi)容，但閱讀論文和參加小型的、更有針對性的聚會通常會更好

6.7.4. 對于想獲得實用技巧和想會見有經(jīng)驗的從業(yè)者的人來說，那些基于興趣的聚會非常好，可以找?guī)讉€這樣的聚會去參加一下

6.7.5. 供應商展示會一般是較大和較吸引眼球的。它們是大型科技公司的營銷工具，但不適合學習

6.8. 如果你開始覺得你不再有學習進展了，可以去當?shù)卮髮W看看

6.8.1. 他們有大量向公眾開放的項目

6.8.2. 擴大你的圈子，接觸新的想法

6.8.3. 去上研究生是一個可選項

6.9. 跟班學習并同有經(jīng)驗的工程師結對

6.9.1. 跟班學習并同有經(jīng)驗的工程師結對

6.9.1.1. 跟隨者是一個積極的參與者

6.9.1.1.1. 他做筆記并提出問題

6.9.1.2. 隨一名高級工程師是學習新技能的好方法

6.9.2. 結對編程(pair programming)也是一種很好的學習方式

6.9.2.1. 兩名工程師一起寫代碼，輪流打字

6.9.2.2. 這需要一些時間來適應，但這是相互學習最快的方式之一

6.9.2.3. 結對編程也不僅僅是針對初級工程師的，所有級別的隊友都可以從中受益

6.10. 用副業(yè)項目實踐

6.10.1. 從事副業(yè)項目會讓你接觸新的技術和想法

6.10.2. 當你只有自己工作時，你可以跳過那些被稱為“軟件工程”的環(huán)節(jié)（測試、運維、代碼評審等）

6.10.3. 忽略這些方面可以讓你快速地學習新技術，只是不要忘記在工作中還有那些“真實的”環(huán)節(jié)

6.10.4. 可以參與開源項目。大多數(shù)開源項目歡迎所有人貢獻力量。這是一種學習和建立職業(yè)聯(lián)系的好方法

6.10.5. 不要根據(jù)你認為你需要學習的領域來選擇項目

6.10.5.1. 找到你有興趣去解決的問題，并使用你想學習的工具來解決這些問題