[The Effective Engineer 翻譯筆記] Introduction
今年初付了錢買了這本書的電子版，但一直沒時間看，感到很可惜。最近又想說要多練習寫作，就來看一段章節，寫一段心得。寫一寫之後發現，我想寫得很詳細的話，會變成有點像在翻譯，所以我會盡量提醒自己簡略，並用我自己的理解重寫句子，在原文翻譯和心得中間取得一些平衡。
另外如果想快速吸收這本書精華又不想逐字看書的話，可以直接看作者 Edmond 在 Google 的 talk。
Introduction
作者講了他前幾年在 startups 工作時，整個 team 的周工作時數不會低於 60 小時，而且常常在吃午餐時順便 meeting，晚餐後也繼續工作，甚至假日陪家人時也在 coding 和回覆 email。
他當時覺得，startups 應該要花夠多的時間來跟難纏的對手競爭，他們 working harder，就越有機會提高生產力，也越容易取得成功。
但後來的一些經驗讓他覺得，必須重新考慮這個假設，來自於他們打造了一個客製化的分析工具，可以為使用者帶來更高品質的內容產出，花了兩週打造，但是使用者卻不買單，成了沒有人要用的產品，還白白浪費他們的主機資源和開發時間。
這就讓他不禁開始問自己，除了 working harder，是否還要 working smarter？如何分辨哪些才是有 impact 的產品？如何花更少的時間產出同樣程度的 impact？
到這就導出了他的結論，如果你是一個 effective engineer，你就要有能力去 identify 哪些生產活動是可以投資更少時間，卻獲得更大產出。
What Makes an Effective Engineer?
如何衡量工程師的效率？是用她(原文用 she)的工作時數嗎？還是他(原文又用 he)付出多少努力？她(又改用 she 了)完成的 task 數量？如果一天結束，一個很努力的工程師付出她所有精力做出的東西，最後卻沒人用，那這不能算有效率的工程師。他說他自己之前就是這種工程師，很多很厲害的人亦是如此。
超過十年，他在滿多科技公司當過工程師，包括 Microsoft、Google、Ooyala、Quora，現在在 Quip。「What Makes an Effective Engineer ?」這個問題他會一直提醒自己，他想增加 impact 但持續每週工作 70 - 80 小時並不是個好解法，所以他總是會想如何花更少時間，但完成更多。
其他人也會碰到這問題，因為實際上其中一個場景就是 hiring 這件事，他參與了各種工程師面試，看過幾千份履歷，面試過超過 500 的應試者，不停的討論，最後要決定時總是會問：「這位應試者之後可以成長為 team 裡夠強的 contributor 且夠 effective 地把事情完成嗎？」這是他們會一直問自己的問題，以求整個 team 是 effective，形成整個公司的文化。
不只 hiring 時做這些，他也打造了 onboarding 和 mentoring 的 programs 給新進員工，有了這些東西，他可以讓新進的工程師加速成為有戰力的 engineers。如果不如此，以我個人的經驗，菜鳥一開始架設開發環境或是摸索公司的架構時，會一直問資深的人，來來回回會浪費資深工程師的注意力。如果每次有新人都要花這種大量時間，就能想像這種公司在 scale 時的速度之慢。
如果有完善的 SOP 就能花費更少的人力，有了這些 SOP 後就能 reuse，做一次用好幾次。他花了幾年做了各種實驗來加強並驗證 SOP 所達到的生產力，team-building、personal psychology、self-help book 等等。最後就提出了一個他自認為 powerful 的 framework，會在這本書裡面教大家。
最後又再舉了一個例子，我猜是他切身之痛，因為還滿具體的。他說一個人有效不算有效，
Effeciency alone doesn’t guarantee effectiveness.
如果一個人獨自打造了可以 scale 到處理百萬級 requests 的內部工具，但最後最多只有一百人在用，這樣並不算 effective。因為只有 0.1% 的 users adopt，比不上另一個 feature 有 10% 的 adoption，除非，你那 0.1% 帶來更大的商業價值。
所以這裡就很清楚的定義他們的 effective，這本書所謂的 Effective engineers 專注在 value 和 impact，至於你花多少努力，產出多少功能，做完多少事，那都不是有效的依據，而是你做的單位時間和努力，最後兌現成了多少價值。
What You’ll Learn from Reading this Book
整本書並不會看到任何一行 code，比較多會看到的是各種技術、程式語言、軟體框架和系統架構的內容，會給一小部分的 skills 讓工程師依序學習，學完就會比較 effective 了。
這本書會教滿多 meta-skills，中文我不知道怎麼翻，我猜會翻成「元技能」吧？這些元技能會幫你判斷你需要把時間專注在哪些事物上，如何把你的努力用最大轉換率換成 impact。The Effective Engineer 跟你保證的是，他會教你這些元技能，然後得到一個 useful framewrok，他取名叫 leverage。
a useful framework, called leverage, for analyzing the effectiveness of different activities.
這些元技能是作者從自己的經驗中、其他工程師、還有開了幾堂研究課歸納出來的，並且請教各種矽谷的資深工程師、senior manager、directors、科技公司的 VPs，從他們的經驗中萃取出來。
第一章會讓我們學到 leverage 這把尺，讓我們去衡量所謂的 effectiveness 程度，每個子章節會找到 high-leverage 的習慣，伴隨不同的研究、故事和例子。例如 Instagram 的 co-founder Mike Krieger 如何讓 13 人的小 team 去打造一個產品可以支撐超過四千萬的使用者，還有前 Facebook director Bobby Johnson 如何培養他們的 infrastructure team 去打造可以應付十億級使用者的社群網路。除了這些我們會學到來自 Facebook、Google、Dropbox、Box、Etsy 等等其他科技公司的故事，他們都會分享他們的哲學思想，如何領導，如何做更有價值的事。
整本書分成三個部分，Part 1 讓你可以有更嚴格清楚的 mindset 去判斷如何增加你的 effectiveness，Chapter 1 會給出整個 leverage mindset 的輪廓，Chapter 2 教你如何加速學習，Chapter 3 教你常見的 prioitization，分辨哪些是更重要的事，加速個人成長和把時間利用最大化。Part 2 有關執行，很多工程師看了很多卻不太執行，這 part 就是教你更深入的不斷執行，Chapter 4 給你幾個 key strategies，讓你不斷的執行並迭代，Chapter 5 衡量有效性，Chapter 6 讓您更早驗證假設是否有效，Chapter 7 教你事先評估 project 會需要用到 skills。Part 3 強調的是 Effective engineers 不炒短線，他們更重視長期投資的價值，Chapter 8 學習如何權衡品質和現實，Chapter 9 學會最小化營運成本，Chapter 10 是如何投資團隊的成長。
序的最後說，不管你是想要增加你對世界的 impact，還是晉升快一些，或是浪費更少時間達成更多等等，The Effective Engineer 給你的就是 leverage 這個 tool，整本書不是萬靈丹，但你可以從 leverage 這工具學到很多。教學和指導是作者的熱情，他很興奮地要跟你分享他學到了什麼。
Next
我的下一篇文章應該就會進到 Part 1: Adopt the Right Mindsets 的 Chapter 1: Focus on High-Leverage Activities 了吧！如果有人也看過這本書，覺得我有理解錯的地方拜託留言告訴我，因為我英文不是非常非常地好XD
