貼文

每本書,都是一扇任意門。

貼文

關於

標籤

收藏

作品

夜間模式

徐可可badge logo

@ivanhsu

《 The Effective Engineer》作者 Edmond Lau 導讀,增加 impact!! 矽谷工程師都在做的事。

2023-05-11
post image

在傍晚吃飯時間,看著 VSCode 上抽象再抽象的程式碼、Terminal 上惱人的錯誤訊息,這時 Slack 又跳出通知,有緊急的 Bug 票需要解決。螢幕右上角的時鐘,不知道什麼時候已經又過了一小時。明明下班時間都已經到了,今天的進度卻才剛開始沒多久。這時候你不禁感嘆,上班就和爬山一樣,下班路比上班難

你是否有過這樣的時期,上班的時候事情永遠做不完,今天的進度一直往後堆積,每到禮拜五總是加班到接近12點。內心開始自我懷疑,是不是技術能力不足、效率太差,還是工作真的太多了。

最近發現幾個技術部落格都推薦了《 The Effective Engineer》這本書,說非常受用,於是我決心來好好研讀一番,期許未來自己也能夠成為一位 effective engineer。

我先看了作者在 Talks at Google 的演講,這場演講涵蓋了《 The Effective Engineer》的主要內容。本篇文章會重點摘要演講的內容,書的內容等我看完之後再另外寫文章發表。

作者 Edmond Lau 在許多知名的矽谷大公司(e.g. Google)和新創公司(e.g. Quora)工作過。他曾經連續 2 年每週工作 80 小時以上,並且又花了 2 年,全職研究如合成為一個 effective engineer。

藉由訪問 20 幾家矽谷科技巨頭以及新創公司(e.g. Facebook, Instagram, Dropbox, Etsy 等等)的 CTO 和技術大神,問他們以下 3 個問題:

  • What separates the most effective engineers you have worked with from everyone else?(什麼事情造就了有效率的工程師,使他們有別於普通的工程師?)
  • What is the most valuable lesson you have learned in the past year?(你過去一年之中,學到最寶貴的教訓是什麼?)
  • What investment you have made for your team has paid off the highest returns?(什麼投資給你的團隊帶來了最高的回報?)

總結出每個軟體工程師都可以學習的效率工作法。作者稱之為 leverage framework。

這本書裡不會有任何一行 code,書中所闡述的,是作為一名軟體工程師,如何藉由執行 high-leverage activities 來最大化自己的 impact,槓桿出自己的價值與影響力。

作者要我們了解一個殘酷的事實:

effort === impact // False

努力不等於影響力與貢獻

一位 staff engineer 的產出貢獻,可能是一位 junior engineer 的 10 倍,但是前者的工時,不可能也是 10 倍。

作者在此給出了本書的核心概念「leverage」,它是一個放大器,可以將你的努力轉換成巨大的產值和影響力,同時也是突破日常開發瑣事的施力點。以下是 leverage 的計算公式:

leverage = impactProduced / timeInvested

工程師的開發日常,也符合 80 / 20 法則。20% 的任務創造了 80% 的價值和影響,而 80% 的任務,只帶來了 20% 的成效。

作者要我們辨識那些花最少時間,卻能創造最大價值和影響力的事情,並且優先去執行它,這些影響至關重大的事情叫做 high-leverage activities

在演講中,作者提及了以下 5 種 high-leverage activity ,就讓我們一一來了解吧!

Optimize for learning

第一個 high-leverage activity 是最大化自己學習能力。因為,學習是有複利效果的!所以越早開始進步的幅度越大,學習能力越好,進步得越快。

Learning compounds!

因為學習具有複利效果,所以能力的成長曲線呈指數增長,一開始緩緩上升,幾乎是平的,但過了某一個臨界點之後,會近乎垂直地向上攀升。

這也滿符合事實,當要攻克一個難題時,需要累積不同面向的知識,當知識點連成線之後,就能夠兜出解法解決問題了。

作者舉了一個老生常談的例子,每天進步 1%,一年後,會進步 37 倍!

要努力學習這個大家都知道,但困難的地方是,我們常常被淹沒在日常的開發瑣事、隕石一般的 bug 轟炸之中。每天要做的事情都做不完了,要怎麼騰出時間來學習呢?

在書中,作者舉了一個 Google 的例子,為了提升員工的生產力與創造力,Google 實行了 20% Time,每週空出一天做自己本職工作以外的事情,研究新的技術、做自己有興趣的專案等等。例如 Gmail 就是從 20% Time 中誕生的。

但是身為一般公司的員工,不可能每個禮拜空出一天。於是作者建議,我們可以每天預留 1 小時的工時,來實行自己的 20% Time

關於學習的最後一點,作者建議我們可以從自己感興趣,或是工作上面臨的問題著手研究,因為動機永遠是持續一項行動最重要的元素。

Invest in iteration speed

第二個 high-leverage activity 是加速處理重複事務的速度。這和決定是否要將一段 code 寫成一個 function 的判斷方式一樣,當一件事情重複做第二次的時候,你就應該想辦法讓第三次作業能夠自動化地進行

在作者問了每個 CTO,什麼事情造就了有效率的工程師,使他們有別於普通的工程師的時候,他們回答:「會投資時間自己寫一些自動化小工具的工程師,往往效率都是最高的。」

這裡說的小工具,小到 shell script,大到整個 CI/CD 的自動化基礎建設,都包含在內。

作者舉例,之前他在 Quora 工作時,每天平均會部署 40~50 次,可以想見如果沒有 CI/CD 的自動化流程,會花費多麼龐大的時間。

許多矽谷的大公司都有專門的 team 在打造內部開發工具,像是 facebook 開發了 React.js。作者說:「我們都很想成為某個新潮 framework 的作者,但其實,從每天的開發日常,就可以開始了!」

Validate your ideas aggressively and iteratively

第三個 high-leverage activity 是盡量在進到實作的階段之前,就先驗證 feature 的可行性,避免浪費不必要的時間以及人力。

舉例來說,Etsy 把產品搜尋結果頁面改成可以無限捲動。在上線之前,他們做了 A/B test,發現點擊率和轉換率各自下跌了 10% 和 25%。因此,這個功能最後根本無法上線,白白浪費了幾個月的時間和人力。

有了這次的經驗,Esty 在修改產品內容頁面的時候,採取漸進式的做法,先將想做的 feature 拆解成幾個可以驗證的前提假設,確認對產品有幫助之後,才真的開始開發。

作者說,在一個專案裡,越是不確定、有風險的事情,越要在第一時間執行,避免後續做白工。

Minimize operational burden

第四個 high-leverage activity 是要盡量降低日常維護的成本,作者在演講中著重在複雜度 complexity 的討論上。

當 Instagram 被 facebook 收購的時候,服務著 4000 萬的使用者,員工卻只有 13 人,其中只有 5 位是工程師。無論從什麼角度來看,他們絕對是一個超級有效率的團隊。

作者訪問他們的 CTO,是什麼造就了這一切?CTO 的回答是:「我們只採取最簡單的做法來解決問題。工程師們互相詰問,確認不會增加後續維護的成本之後,才會進行開發。」

作者說複雜度的影響,從小至大都可能存在。

code complexity -> system complexity -> product complexity -> organization complexity。

複雜的 code 會增加工程師的理解和互相溝通的成本、系統的複雜度會增加維護的成本、產品功能的複雜度越高,會讓未來開發的功能的難度增加、甚至是組織上的複雜度,都會影響到開發團隊的效率。

作者有一次在夏威夷休假,但是剛好有一個只有他懂的系統出問題,而火山上面沒有網路可以處理 bug,於是他就直接變成 single point of failure 了⋯⋯

於是作者開始重視 mentorship,製作詳盡的 on boarding 文件和流程。原本入職三個月的工程師還在理解 code base,現在剛入職的工程師,在第一個禮拜就可以開始貢獻 production。這真的是非常巨大的效率改善!

Building a great engineering culture

第五個 high-leverage activity 是建立良好的開發團隊文化。工程師們都想在聊好的環境中工作,專注於 leverage activities,會成為一個正向循環,讓效率推進越來越順手。

最後是一些 Q&A:

Q: 寫測試雖然必要,但是很花時間,有沒有更有效率的寫測試方法?

A: 可以先確保重要的環節都有測試覆蓋,在頻繁的改動下不會出錯為目標。

整個系統不一定要有 100% 的 test coverage,在很少用到的地方寫測試,有時候可能是一種浪費。

Q: 你提到的例子都是新創公司或規模不大的公司,關於減低複雜度,有沒有在大公司也適用的方法呢?

A: 新創公司的好處是大家容易直接溝通,但大公司也有它的優點,例如容易取得歷史數據。

以 Google 來說,它是一間非常 Data-driven 的公司,所以可以讓數據說話,影響決策者做出 leverage activities。


這篇文章是我和耶宣聯名合作的文章,我們各自對於「如合在職場展現自己的價值」發表一篇文章講述我們的看法。

歡迎點此連結,閱讀他的文章唷! 以及追蹤他的 IG 倪耶宣「懶人如何打造複利人生」? @goodyesyuan 唷!


最後,也別忘了追蹤🚪每本書,都是一扇任意門的 IG 唷!@page.turner.weekly

翻開下一本書,我們會身在哪兒呢?🚪

 4 0

推薦文章