這是我跟 Ruby-on-Rails 實戰聖經作者 ihower 對話的下半場。上半場的內容在這裡。

Bernard：剛剛我們討論的都是工具。現在我們把層次拉高一點。作為一個軟體工程師，有什麼技能是一定必須的？我想應該不是程式語言或是工具，而是更底層的東西。或是說，在你面試求職者，或是管理你的團隊時，甚至在管理自己時，你最在意的特質或是能力是什麼？

ihower：我很在乎一個人格特質，就是 ...「擔當責任」。具體來說會有幾個重點：

第一個是對自己犯的錯負責。例如，軟體工程師所犯的錯就是 bug ，所以當你寫的程式碼在 production 上有錯的時候你該怎麼辦？你就是要去負責修好它，然後誠心誠意的跟你的主管與客戶道歉。也不一定是客戶，可能是同部門工程師，也可能是客服部門。

我有碰過比較 junior 的工程師，他會跟我說「程式碼裡有 bug 是很正常的」。這是一句很不負責的話。它也許是事實，但是站在「負責任」的角度上面，我覺得這是不是很好的態度。

第二個是你對你的產出要有信心，你寫出來的程式碼是 OK 的、正常的。

我很在乎一個人格特質，就是 ...「擔當責任」

Bernard：什麼意思？

ihower：就是要確認你寫出來的東西上 production 後不會讓產品爛掉。怎樣確認不會爛掉？就是要去測試、去 QA。這裡不說的不一定是指自動化測試。作為一個工程師，你也可以要手動去測試，自己程式碼放進去後，產品是能一樣正常運作。

有些 junior 會覺得他這次修改的程式碼非常間單，所以就認為不需要做任何手動測試，而直接 deploy 出去，然後就爛掉。

Bernard：所以是對自己的產出要抱有一定的嚴謹度，對不對？

ihower：可以這麼說。但我覺得也是「擔當責任」的一部分。因為這段程式碼就是你的責任。

我認為工程師需要注意去判斷 regression 的風險。其實跟醫生常講 “do no harm” 的道理一樣。就是你要去確保你新加的程式碼是不會對 regression test 有傷害的。當收到團隊的 pull request 時，我會特別看重會有 regression 風險的。在 code review 時我會看得比較認真、比較仔細。

Bernard：那如何判斷這個風險到底有多高？

ihower：這件事可能比較吃經驗值。可以說，新加的程式碼通常比較不會有 regression 的風險。但如果在這個 pull request 你改了一大堆本來有的程式碼，regression 風險就相對高很多。

我認為工程師需要注意去判斷 regression 的風險。其實跟醫生常講 “do no harm” 的道理一樣。

Bernard：瞭解。的確，很多 junior 的工程師不會去注意 regression 的風險。

ihower：對，還有一個比較容易漏掉的，就是現有資料的問題。蠻多 regression 是 data dependent 的。就是你的專案已經跑一陣子，是一個已經上了 production 的案子，所以在 production 資料庫裡有真實的資料。而你改的程式碼跟那些資料，會不會產生一些錯誤的互動，造成 bug。你在本機端做開發的時候，用的是一套完美的 data。但 production 上面 data 不一定是。所以你要確認的新加或是修改的程式碼，能正確處理 production 上的資料。

Bernard：感謝老師的分享。非常受用。我們來聊些更個人的。在你的職涯種，你的動力來源是什麼？當然現在可能是家裡有小孩要養，而在不同階段不一樣。但是否有一個共通的動力來源？

ihower：就是剛剛提的，喜歡學了會變強的感覺。

Bernard：那你可以分享一些你個人曾碰過的職涯瓶頸嗎？以及你是怎麼去突破這些 bottleneck 的？有沒有一些案例可以跟後輩分享？

ihower：我個人的瓶頸是當時我在外商當 CTO 的時候。那一份工作對我來說是很大的挑戰：第一次去外商，第一次帶數十人的工程團隊，需要跨部門的聯繫。而團隊又是跨國的。所以在溝通上有語言與文化上的挑戰。技術上也有挑戰，那時候要建立一個分散式 (distributed system) 的應用。在這之前自己在這方面經驗也比較不足，所以是一份壓力非常大的工作。

Bernard：那你後來如果克服這些挑戰？

ihower：我其實並沒有克服這個環境，而是了解到自己的個性可能並不是這麼適合辦公室，所以後來我決定轉換不同的工作模式嘗試看看。

Bernard：後來你就來了 ALPHA Camp，為培育人才做貢獻。

ihower：

Bernard：最後一個有關「產業環境」的問題。你跟我都算是在 2000 年初開始進入職場。過了十多年後，你看到現在的工程師，不管是你親自帶的團隊，或者是外面跟你請教的後輩，他們現在碰到的職涯的挑戰或是瓶頸，跟你當年有什麼差別嗎？

然後你會給他們什麼建議？

ihower：我覺得相較於早期，就是 2000 年出頭的時候，你如果要開發 web app ，你學一個 PHP 就差不多可以了。那時候 JavaScript 根本不成氣候，前端也沒有現在這麼講究。所以你會寫 PHP，你就可以做個「無名小站」了（Bernard 註：年輕人，你有聽過【無名小站】嗎？）

我覺得現在這年頭技術變的又多又變雜。不是說做一樣的事情會變難。其實工具變得非常強大。例如如果是 web app，你只要去學 Ruby-on-Rails 就可以做到比以前多很多的事情。問題是各個新的領域的內容都變深很多。像是前端框架、DevOps、甚至是 AI 人工智慧等等，令人非常眼花撩亂。

對現在的工程師，挑戰會變成是，如何找到自己喜歡的。你也搞不清楚每個技術自己喜不喜歡，或者是是不是值得去投入時間去研究。而研究後是否能找到工作等等。

這該是現在年輕軟體工程師在職涯發展上碰到最大的問題。

現在挑戰會變成是，如何找到自己喜歡的。你也搞不清楚每個技術自己喜不喜歡，或者是是不是值得去投入時間去研究。而研究後是否能找到工作。

Bernard：所以該如何面對？是建議去多嘗試？還是要更專注一點？

ihower：去嘗試是吧。應該是說，每個技術要學個皮毛，應該是不是很難的事情。不論是前端或是 DevOps。其實學個幾天、幾星期，該不算是很難的事情。現在線上課程與其他學習資源這麼多。學完一遍皮毛，大概就可以了解你自己真的比較喜歡什麼，然後再自己喜歡的深入去學。

Bernard：這樣可以了！感謝老師！最後，有什麼要跟後輩說的？

ihower：沒有，我沒有好為人師。

Bernard's takeaway:

我認識 ihower 是在創立 ALPHA Camp 的時候。當時我主動跟他聯絡，邀請他對我們的課綱作回饋。他人非常友善、也很熱心。轉眼之間就六年了。他跟我認識的「頂尖」工程師有很多共通點：頭腦清楚、注重細節，對自己與團隊都很有要求。

但就算是有過人的能力，ihower 也碰過自己無法突破的瓶頸。但後來也因為這樣，才更瞭解什麼環境適合自己。這幾年 ihower 相對低調，專注在不同的領域挑戰自己。先是接了北京的專案，去打造大流量的產品，同時去瞭解中國市場的遊戲規則。後來更往電商、創業、管理等領域發展，繼續追求他喜歡的那種「學了什麼東西後會變強這種感覺」。

有關選擇什麼技能學習 — ihower 的建議也讓我反思。曾有校友問：「我做了幾個 Vue 的專案，那我是否該學一下 React 呢？」

我會認為，如果你在工作上需要使用 React，能馬上學以致用，我覺得可以。又或是你有嚮往的企業，但他們指定的框架是 React，那樣也可以。我觀察到國外的企業越來越多是使用 React 了，而工具的經驗的確會影響到你能選擇的職缺。但重點是你要深化手上的工具技能，也不要隨便「為了學習而學習」。

這篇是 ihower 推薦的參考文章：Learning deep and wide, not duplicate

那你的成長動力又是什麼？