新創公司優秀軟體工程師的必備特質

Contents

原文 : What Qualities Make a Good Startup Engineer？

Soft & Share 取得 The Effective Engineer 作者 Edmond Lau 授權翻譯。

不是每一位優秀的工程師是一位很好的新創工程師。我在過去的六年中在三家新創公司(Ooyala， Quora，和 Quip)面談過一些最有希望的應試者，他們在頂尖的科技公司像是 Google 已經有 5 年以上的工作經驗，在我們面談過程中表現並不好。這些候選者平時並不是不好的工程師，事實上他/她們在目前的工作上表現非常出色，我們只是認為他/她們對一家新創公司而言並不是特別的出色。

在花了多年的面試應試者，並培訓和指導其他工程師，我發現的確有一些特質能讓程式設計師在新創公司裏更容易成功。終究，這些特質來自於新創公司的工作方式不同於穩定公司的工作方式。在新創公司

你有比較多的機會可以著墨在產品，軟體系統，團隊和你造就的文化。
你的成功更多取決於團隊的效能高於你自己的效能。在一家大型與穩定的公司，你可能會被提拔與攀升職涯階梯，純粹根據你個人貢獻的強度。在小型的新創公司甚至大概沒有所謂的職涯階梯。
時間更加重要，有兩個原因，一方面是新創公司往往還沒有達到獲利能力和敏捷性，另一方面敏捷是他們的主要優勢去對抗已經根深蒂固的競爭對手。有限的時間意味著你必須迅速擴大，沒有奢侈的時間去磨蹭或是在錯誤的優先順序工作上花了太多時間。

我曾經一起共事過最有效率的新創軟體工程師都有很好的決策能力及工作技巧去有效率地操控航道。特別的是他們都表現具有下列 7 種特質。

系統的除錯技巧。軟體開發時間有相當大一部分是實際上是花在除錯和理解一個複雜系統的內部原理。一位客戶回報了一個緊急的問題，你得立刻修復好這個問題。伺服器的 CPU 負載呈現高峰，你必須去理解為什麼會這樣。數據損壞了，你必須找出罪魁禍首。優良的偵錯與除錯技能夠讓你更快地完成工作。有效率地除錯需要對問題是採取嚴謹、科學的思維: 制定一個哪裡會出錯的假設，然後找出最有效率的方法或是一個最小可重複步驟案例(minimal reproducible case)去測試這個假設。其它部分涉及必須會流暢地使用範圍廣泛的工具: profiler 工具可以幫助識別效能瓶頸在哪裡，偵錯器可以一步一步地讓程式碼執行，git bisect 縮小範圍找出一個退步原因，使用 UNIX 指令 fu 去細部拆解目前發生了什麼問題。(註1)然而，除錯的主題適用於更廣泛不僅僅是技術領域。產品的使用與成長已經趨緩–你如何去制定和測試關於使用者行為的假設並且對這個趨勢去除錯？團隊沒有打中他們的專案目標–你如何去除錯是否根本原因是專案預估能力太差，團隊溝通不足，太多的工作切換(context switching)，或是其它原因？招募活動沒有招聘到夠多你希望招聘的工程師–你如何除錯是否是人力來源管道的問題，你的面談方式，你提供的薪資？(提示: 從數據開始)
無畏地投入你未知的領域。做為一名新創公司的工程師，你經常需要鑽研較大和不熟悉的基本程式碼(codebase)，你可能還要挖掘你正在使用開源工具的原始碼，因為它的表現不符合你的預期。或者，你可能需要了解其他同事的程式碼，因為他/她可能沒有時間修改，快速瀏覽大型程式碼庫的能力和在關鍵的相關部分程式碼磨練。這種能力有很大一部分是來自於閱讀了大量的程式碼經驗。其它部分來自熟悉工具去搜尋程式碼庫，跳到相關部分的程式碼，在版本控制歷史記錄找出相關的程式碼提交記錄–所有這些捷徑可以減少花費時間在了解不熟悉程式碼上。這種無畏的精神也在成熟穩定的公司很有幫助。但是你可以經常成功藉由只專注於程式庫的一部分，並且對這些程式碼了解的很好。你鑽研進去不熟悉的部分，然而不一定與程式碼相關，以下這些工作在新創公司並不會罕見，例如工程師要處理客戶支援，跟業務一起合作提高滿足客戶需求的可能性，訓練新進的工程師，和其它你可能不熟悉的工作。在經歷其中並做好這些工作時，採用成長的思維是很重要的。
對決策務實的態度。對於一個表面上堅持優良的軟體開發實踐堅的人例如程式碼審核和單元測試可能在較大的公司要幫助組織擴展是重要的。(註2) 但是對於新創公司，必須注意在你的權衡考量上更多加務實和要團隊做什麼事可以讓事情可以更快地完成。實用主義意味著知道什麼時候打重要的戰役和甚至當你不同意決策時什麼時候比較好去接受它所以團隊可以團結一心並能取得進展。我見過在程式碼風格(coding style)意見不同而爆發衝突–是否一行程式碼的長度是 80， 100，還是 120 個字元和大括號不應該放在一個敘述的結尾。但是最終還有較困難和重要的決策需要你花時間和精力在上面。評估最重要權衡得失的引導啟發應該基本上是：“什麼樣的行動最終將增加團隊成功的機率？”，許多因素可能會關係到這個問題：產品選擇，架構權衡，團隊文化，人和更多其它因素。但也有很多沒有關聯。對於這個問題最佳的行動過程會是不要去限制討論的時間，對於一個決策承諾到底(不知變通)，保持前進。(註三)
工具建置思維。工具讓你擴展你最重要資源的極限–你的時間。有效能的工程師構建了很多工具，這在新創公司更重要，在這裡，你的時間是更有限制關係到要完成多少事情。大公司可能有專門的工具團隊來幫助工程團隊更有效率。在新創公司，由較能勝任的你來擔任工具建構者，將更多手動執行的工作做自動化處理，如果這些自動化工具也被其他同事所採用，這對於生產力是一個很大的倍數增加。
強大的通才。特別是在新創的早期階段，很多面臨的問題並不需要專家等級的知識。更廣泛你會的技能，即使它只是極小的技能。工作中熟悉多樣化的技能–你會發現在你的執行路徑上越少遇到瓶頸。例如，一位做前端開發的網頁程式設計師如果有後端的基本開發技巧，將可以在產品雛形階段更有效率的除錯而不需要已經很忙碌的後端工程師的幫忙且佔用到他/她們的時間。後端工程師基本的HTML ，CSS 和 JavaScript 技能，可以為他/她們建構的工具做出一個網頁前端介面，讓更多團隊成員可以使用，而不需要佔用到一位前端開發者的時間。負責使用者成長的工程師對於基本資料分析工具很流暢的使用，可以自行針對所做的實驗分析而不需要佔用一個數據分析工程師的時間。有一個例外，如果你的公司是從事於利基型技術則需要更多的專才，例如資料庫新創公司，需要更專精的工程師才能更有效能。還有，新創公司初創後較晚期階段，有了足夠的人填補特定的職缺，這個職缺是你可以負擔得起並找得到人幫忙。
渴望成為一位參與者而不是一位受害者。Fred Kofman 在他的書 Conscious Business 描述了兩種面對任何問題時可採用的態度。我們可以是受害者並且責怪任何因外在因素引起的問題( 延誤了專案的最後期限，產品一推出就搞砸了，或是同事之間的衝突 )。或是我們可以是參與者並且辨識在我們影響能力範圍內的形勢，集中精力和努力朝著我們實際上可以影響並修復問題。在短期內，受害者思維模式可能會讓我們自我感覺良好，但是最終採用參與者思維模式是唯一可以有效能地進展的方法。在新創公司上班是很有壓力的。隨著高度壓力，很容易落入一個譴責的遊戲，推卸責任，而不是承擔起個人可以控制下的責任。不幸的是，這個路徑只會導致失望和不滿。
結合學習的意願和自我反省的毅力 一個對於其他優秀軟體工程師特質的關鍵觀察是他們的技能都是可以透過學習得到的–假設你的動機夠強的話。長期積極地去學習這些技能來自於一個特質叫做毅力。Angela Lee 在她的 TED 演講 “The key to success? Grit” 給這個特質做了一個很棒的定義：

毅力是為了長遠的目標的熱情和堅持不懈。毅力是擁有耐力。毅力與你的未來結合在一起，日復一日，不是只有一週或是一個月，而是數年如一日，並且要非常努力將未來變成真實。

如果你願意投入時間定期回顧反省，你就會了解什麼部分是你最弱的並且哪裡要改進。隨著時間的推移和經驗增長，你將會成為一個更好的新創軟體工程師。只要早期對你在對的方向一點點輔導與指引也可以走很遠。

以上這些特質對於在已經很成熟公司工作的工程師也是很有幫助；這些特質對於新創公司更加重要的原因在於新創公司的時間更為有限。此外，缺乏這些特質並不一定意味著你是一位糟糕的工程師。這些只是意味著你可能不太適合在新創公司的環境。但是，如果你決定要成為很好的新創工程師，不要因為這些原因阻止了你。規劃好你的行動計劃，以改善這些技能。

這篇文章源自作者 Edmond 在 Quora 上的回答。

文中註釋

Command Line Fu, xkcd.

For instance, I learned a lot about scaling engineering teams while at Google: What Google Taught Me About Scaling Engineering Teams. But at a startup, it’s important to be pragmatic about applying those lessons.