個人的全書總結，整本書圍繞著有很多事情要做，在選擇不同的事情上，選擇上應該多著重在長遠的、有效的來當戰略，而不是與之相反的在短期的、只著重在效率上的戰術。
這裡的有效（effective）與策略（strategy）指的是長遠來看效益很高、會隨時間有著槓桿（leverage）成長的。
這裡的有效率（efficiency）與戰術（tactic）指的是短期的、以快速為目的達成目標。
基本上高手講的都一樣，不要用戰術上的勤勞掩蓋戰略上的懶惰，好的戰術可以打贏一場戰役，好的戰略可以打贏一場戰爭。
一個月裡每天花一小時帶新人可能很划算
一般來說一年的工時大概會是18002200小時，一個月工作天數算22天，每天一小時也就是22小時，算下來只花了一年可能只有1%1.2%的工時。
新人的成長，比方說學會怎麼更好的debug，可以讓新人之後都能省去很多時間，跟沒學會debug比起來，越早學會越早開始有更好且更多的產出，長遠來看會是很划算的投資。
如何增加產值？
一般來說，在單位時間內產出的價值能增加的方法有三種：
- 降低完成一項活動的時間
- 增加一項活動的輸出
- 選擇做其他更有價值的事情
也就是三種問題：
- 怎麼樣可以在更短的時間內完成一項活動？
- 怎麼樣可以讓完成的一項活動更有價值？
- 有沒有其他事情做了會產出更多價值？
如何避免拖延？
IF-THEN方法：如果吃完飯，然後就看教材；如果怎麼樣，然後就怎麼樣，自動的去執行，不要留有意識的來做選擇
盡早且頻繁的取得回饋
越晚越不頻繁的取得回饋，路走偏了越晚修正就越浪費資源
有測量數據，有明確的改進理由與成效
If you can't measure it, you can't improve it.
選出好的測量數據當改善的指標非常重要，比方說Google測量使用者停留在搜尋結果的情況來判斷搜尋的品質
- 測量生產力 > 工時
- 頁面停留時間（long-click） vs. 點擊率
點擊率高有些情況也可能是使用者在找功能，而long-click以Google搜尋來說，最好的情況是使用者點第一個連結，沒有再回來搜尋結果頁面 - 平均回應時間 vs. 95th or 99th 百分比的回應時間
選擇不同的數據當指標，要改善的地方會不同，想要達成的目標可能也不一樣
盡可能的把裝況、發生什麼事情等等的所有事情的都顯示出來
要像開飛機會有一堆儀表板可以看，要知道自己的服務的狀況，以免出事情或是要擴展等等都不知道自己服務的情況
專案延時會因為讓目標要達成的時間去修改了預估的時間
- 把task拆成小的task
- 估時要根據要花多久時間完成而不是希望多久完成
- 估時應該像是機率，而不是總是出現最好的情況
- 讓實際要做該項task的人估時
- 小心錨定效應，估計某一個task最快完成時間後其他東西也用前面錨定的時間繼續估計
- 找多種方式去估時同一個task
- 小心人月估算，人多不一定快
- 根據歷史的估時，來驗證現在的估時
- 研究東西可以研究無限久，考慮給定一個時間來看有什麼樣的結果來竟可能的做最好的選擇
- 讓其他人chanllenge估時
給定明確的目標與milestone
比方說，降低第95th百分比的延遲時間到500ms以內
比較模糊不清比較不好的，在一個月內重寫某某程式
把時程估計列入專案的計畫
- 可以決定在一個時間點是否可以有哪些功能，如果時間點不行，則討論該時間點應該要先有哪些重要的功能
- 時程規劃要有緩衝，要把假期、生病等等的時間也估算進來
- 先把有風險的工作做掉，先做簡單的可能會有進度很快的假象
- 只有在很確定加班趕得上時程的時候才使用加班
code review與測試不一定是要做與不做的選擇
可以只在很重要的地方做code review跟測試，資源有限的情況下不重要的就先跳過
好的batch應該要是重複執行也會得到一樣的結果
好的batch即使執行時某些地方壞掉了需要調整，調整後可以再執行一次仍然得到同樣的結果
或是至少可以retry
計畫一個失敗了以後仍然能很快的復原的模式
失敗了可以很快復原，會比較有信心且大膽的前進
比方說用版本控制系統，寫錯了就回上一版。上線的系統仍然有bug，能很快的回上一個沒有bug的版本
公司的成功會很大的影響個人的成功
Andy Rachleff: You get more credit than you deserve for being part of a successful company, and less credit than you deserve for being part of an unsuccessful company
如何循序的改善面試流程
- 跟組員一同找出將來的組員要有哪些重要的特質
- 週期性的回顧目前的流程是否有效
- 設計不同難度的問題來看面試者的程度
- 目的是要多了解面試者，可以在一些地方給提示，或換問題，不要在一些地方卡太久
- 週期性的找其他組員一起參與面試，看有沒有流程要改善
入職訓練
- 定出目標
- 找出該怎麼達成目標
可能會有mentorship，可能會有onboarding talk介紹工具等等，可能回有個適合的小task來進入專案，看目標是什麼
不要讓一件事情只有一個人能做，share ownership of code
真的有事情急需要救火的時候，萬一能做的人手邊也沒電腦就完了，或是請假，人事變動等等的
回顧工作，蒐集智慧
下次怎麼樣做更好，分享給不同的團隊以免重複採坑
對於前公司工程的文化上哪一點喜歡與哪一點不喜歡
可以知道彼此適不適合，也可以知道哪些東西會讓員工不喜歡