當了兩年軟體工程師，我學到了三條生存法則
編者按：從高校校園進入職場，環境的轉換通常也意味著生存規則的改變。我們在學校裡所信奉和追求的那些在職場環境中是否適用？工作之後，是否只要足夠努力、悶頭工作就能像在學校一樣拿到最好的成績？本文作者 Mitchell Irvin 分享了他進入軟體工程工作兩年之後的所思所想，其中並不僅僅適用於軟體工程師，對於告別校園、初入職場甚至有過多年工作經驗的“老手”都有很大的借鑑意義。
接下來你會看到我的一些個人職業經歷，包括成為軟體工程師以及工作兩年之後學到的一些經驗、教訓和其中存在的一些遺憾之處。
大學和工作場所
2015 年，我還是佛羅里達大學的一名學生。當時，我研修了一門可能是整個學院最難的課程，當時負責授課的教授在課程展開的那個學期內會分配給學生多個團隊專案。在每個專案結束時，這名教授會單獨對每位學生的表現進行評估。然後在分配下一個團隊專案時，他會將之前專案任務中表現最優秀的學生整合到一個組，表現最差的學生會繼續留在他們原來的組。這樣到學期結束時，班裡的學生要麼是竭盡全力並且成功進入了一個強大的團隊，要麼是最終待在了一個表現差勁的團隊。這樣的分配與激勵方式很美妙，強者不必去忍受弱者或者是為弱者買單，而弱者可以選擇讓自己變得強大，否則就只能面對失敗。用“唯才是用”（meritocracy，也有譯為優績制度，指應該根據才能、努力以及成果來評定一個人，而不是根據性別、種族、年齡或財富等其它因素）一詞來形容這一環境系統可謂最恰當不過，這樣的系統獎勵的是那些最有才華的學生，而那些不努力的學生也必須自食其力，自己承擔後果和責任，我真的非常喜歡這種環境系統。
一年之後，我畢業了。當時的我幹勁十足、精力滿滿、胸懷大志，十分理想主義地準備在我過去四年學習的專業領域內大幹一場。實習結束之後，我收到了來自一家大型企業軟體工程師職位的邀請，我接受了這一職位，內心渴望自己能夠成為一名優秀的軟體工程師。
開始我參與了一個專案，這一專案嚴重缺乏相關支援資源。我們負責構建一個 Web 應用程式，這一應用程式的功能與大多數 Web 應用程式的功能無異：公開一些資料並且可以讓使用者操作這些資料。我和其他兩位工程師一起負責開發工作，另有一位質量控制工程師負責測試方面的工作。僅僅幾個月的時間我就開始認為自己是這個團隊中拱心石般的角色，負責撐起一切。使用者需要我們去構建一個新功能嗎？沒問題，我能搞定。需要有人去促成一下回顧會議？當然可以。很快我就發現自己所處的是一個沒有我的努力就毫無進展的環境體系。就這樣，在我 22 歲那年，我在一家財富 25 強企業扮演起了首席工程師的角色。
但是問題在於，儘管我在近一年的時間裡一直承擔著團隊的絕大部分工作任務，我所得到的報酬仍然只是團隊裡其他經驗豐富成員的一小部分。我沒有得到“A”的學分成績，他們也不是“F”，我沒有分到股票期權福利，休假時間也更少了。我不久就意識到了這些，之後很快我的挫敗感就明顯地表露了出來。當與那些不熟悉該軟體的工程師合作時，我很難再對他們保持耐心，很難再展示出樂於助人的態度。我的冷漠感不斷增長，工作效率急劇下降。如果我與另外一位工程師合作負責一項工作，那我保持與他的工作步調統一（即便可能只是我原來工作效率的 5%），我也仍然算是做了我的工作，對吧？
我就是在這樣的狀態中度過了這一專案最後三個月的工時間，專案完成的並不算從容，團隊士氣低落，沒有人為過去這 14 個月的“努力”終於開花結果而興奮。更重要的是，我知道其中一些隊友不會再為將來可能與我合作而心存期待。我這才開始意識到我對於工作環境的態度已經對我以及周圍的隊友產生了不利影響。
幾個星期之後，我發起了一項調查，關於該如何讓自己成為一名更好的隊友這一問題而尋求其他隊友的反饋。最終的調查結果有一點非常明確，那就是個人表現並不能決定一切。在我開始職業生涯之後，我想當然地認為工作場所也是採用 “唯才是用”的分配和選拔標準，就像我在大學校園裡的那門課程一樣，強者會得到應有的獎勵而弱者也會為他們自己的行為買單。正是這種看法影響到了我與他人合作的能力，使我不再感謝他人的貢獻和付出，喪失了謙虛學習和耐心指導他人的品質，團隊其他成員對我的印象也成為了“過於看重個人表現”。
我學到的第一課：你的技術實力（硬技能）很重要，但是你與同事的關係（人際關係/領導技能）與之同等重要。
要想成為一名出色的軟體工程師，你需要用多年的時間不斷磨練自己的專業技能。隨著時間的推移，你會進步、會遇到瓶頸、會上下沉浮，或許也會遭遇鄧寧-克魯格效應（Dunning-Kruger effect，能力欠缺者們沉浸在自我營造的虛幻的優勢之中，常常高估自己的能力水平，卻無法客觀評價他人的能力）所描述的情節。在這過程中，你會犯錯誤，會吸取他人的經驗教訓，也會分享自己的所學所思。毫無疑問，你必須要具備強大的專業技術能力，但是如果這就是你唯一的專長，那你很快就會發現自己處於一個很不利的境地。如果你的目標是成為一名最優秀的軟體工程師，那在通往這一目標的旅程上你必須也要讓自己成為最優秀的隊友（也可能是領導者），而這首先就意味著你要看重他人的付出。
我合作過的最優秀的工程師
九月的一個上午，兩名新簽約的員工加入了我們團隊。因為我們團隊一直以來都以二人配對合作程式設計為安排準則，於是當天我就和其中一位新加入的隊員一起開啟了配對程式設計工作。在接下來的七、八個小時裡，這名工程師，我們暫且稱呼他為 Bob，不停地問我各種問題。在我們開發一個新功能時，Bob 問了一些關於我們所用的語言和框架方面的問題。在我們打磨具體的業務規則細節時，Bob 又問了我關於產品以及我們正在解決的問題方面的資訊。那一天，Bob 並沒有寫多少程式碼。說實話，到下班時，我對 Bob 的表現有些失望。我本來對於他作為工程師的專業技能有著很高的期望，也滿心歡喜地以為自己可以從他身上學到不少東西。
第二天，Bob 和我一起負責編寫另一個產品功能。我寫出了該功能的初始測試用例，並進行試執行，當螢幕上所有的檢查標記都顯示準確無誤之後，我不禁露出了微笑。Bob 在一旁看著，面露沉思之意。在我的測試結束之後，他使用這一測試方法，並且改變了其中一兩行的程式碼。我開始表示反對，“等等！你這樣做不對。”他點點頭表示同意，然後繼續執行我們的測試用例。這樣所有測試都以通過告終，令人驚喜！
幾周過後，Bob 和我依然在這樣配對合作。在我們工作過程中，他依然會不斷地提出問題。在我主導工作時，他會提出一些建議，在他認為合適的時候，他也會介入短暫地佔據主導地位。我問了他幾個關於我們所用框架和語言內部工作模式的問題，除此之外，他還向我介紹了一款我並不熟悉的 OO 設計模型。他對域名和業務問題提出的一些疑問讓我發現了軟體中的漏洞所在，他找出了我們程式碼中所存在的錯誤和缺陷，而這些本來是我根本發現不了的問題。但現在，我也發現了這些漏洞，清晰無比的存在。日子一天天過去，Bob 和我解決了他發現的這些漏洞，對軟體設計進行了加固和防護，大大改善了業務問題和我們所寫的程式碼之間的關係。
在我們團隊合作的整個交流過程之中，當 Bob 認為其他人犯錯時，他並沒有強行去讓他人接受自己的觀點，也沒有偏執地想要去在與他人的辯論中佔據上風。但是他不停地提出問題，在別人回答這些問題的過程中，他們經常會發現自己也存在 Bob 提出的這些疑問。在於軟體相關的幾乎所有的決策過程中，我們幾乎都會發現 Bob 所提出的問題的蹤影。Bob 並沒有就自己對團隊的貢獻而四處宣揚，也沒有拿自己作為工程師的專業水平去壓別人。他似乎並不介意自己在配對合作過程中有多久的時間是自己掌控鍵盤，佔據主導地位。可以說他是我合作過的最優秀的一位工程師。
我學到的第二課：你影響他人的能力取決於你能否幫助他人、引導他人靠他們自己來推匯出與你所做的相同的結論。
Bob 幾乎從不說“我們就應該這樣做，因為……”，他會就你們目前所考慮的一些想法提出幾個問題，到你們討論的最後，你會發現絕大多數情況下，他的問題都會引導其他人與他達成共識。Bob 並不是自己提出什麼完美無暇的想法，通常情況下，他都是先提出幾個問題，然後得到其他人的回答，其中一個問題的答案通常會實現這樣的效果，就是讓他說出“這是一個好點子，我們繼續探究一下”類似這樣的話。但是，就是這樣的方式讓他對我們的軟體質量產生了最積極的影響，因為他擁有著影響我們團隊成員推理過程和方向的強大能力。但是，他實現這一目的並不是通過直接分享他自己的想法，更多的是通過提問的方式來實現。
我學到的第三課：在開始考慮一個問題的解決方案之前，先提出許多的問題，這是一位優秀的問題解決者的標誌。
作為軟體工程師，我們的核心工作就是解決問題。學習新東西是一個需要解決的問題，編碼是一個需要解決的問題，溝通也是一個需要解決的問題。優秀的軟體工程師就是優秀的問題解決者，而要解決問題的一個好辦法就是通過提出問題來理解問題。提出問題表明你尊重他人的想法，提出問題可以幫助你更好的理解事物，提出問題能夠讓你有更大的可能性得出獲得他人認知的答案。最能提出解決方案的人往往就是那些願意花時間去理解問題的那些人。
關於 Bob 的故事還有一點，他在技術方面很有天賦，完全可以成為團隊主力和領軍人物。如果他願意，我相信他都可以成為一名設計師，只是他沒有那個想法。Bob 喜歡寫程式碼，他喜歡做域名分析，喜歡設計業務物件，喜歡編寫測試套件，喜歡交付高質量的軟體。
回顧
回首我做軟體工程師的前兩年可以說是一趟充滿冒險的旅程。我不停地構建軟體、破壞軟體以及修復軟體。我參加了好多無聊的會議，無聊到你真的可以趴在桌上睡著的那種程度。我悶頭扎入工作的海洋，體會著其中的酸甜苦辣。
回看最開始的那兩年的軟體工程師時光，我發現自己有以下幾點需要改進：
-
我將工作放在了人之上。我們工作（產品）的問題總是能夠自己解決，但是與團隊其他成員的關係要維護和修復起來顯然難度指數高很多。
-
我將更多地時間用來環顧四周，而不是向上看，向內看。只是一味地看別人在哪些方面可以做的更好，挑別人的問題，並不能讓自己成為更好的隊友。只有認識到自己的弱點和優勢，你才有機會變得更好。
-
在應該聆聽的時候選擇了說話。只是一味滔滔不絕的講話並不會讓自己變得更聰明，也不會喚起他人的共鳴。
-
在我遇到挫折感覺沮喪的時候並沒有與隊友和領導開誠佈公的交流和溝通。如果他人根本就不知道你的問題所在，那他們自然也幫不上你。
如果你非常看重你的工作並且非常努力，那你可能會成為他人的絆腳石，可能會冒犯到他人，也可能會時常遭遇失敗的挫折。無論怎樣，請一定記住將人放在第一位，而不是工作。要勇於承擔責任，誠懇的道歉，不斷進取。能否做到這些決定著你是隻能做一名普通的軟體工程師，還是成為行業的領導者。
在我接下來沿著職業生涯不斷前進的道路上，以下幾點需要我時刻謹記：
-
目標：成為最優秀的軟體工程師，不積跬步無以至千里。
-
目標：成為最好的隊友。如果我不能積極地處理好團隊關係，那成為優秀的軟體工程師這事就無從談起。團隊凝聚力第一，個人才能其次。
-
目標：分清主次。雖然軟體對我來說很重要，但我的信仰、我的婚姻、我的友情以及我的身體健康比軟體還要重要。想清楚對你來說最重要的是什麼，這一點很重要。我不會為了讓自己工作更高效而犧牲這其中任何一樣。
原文連結：https://blog.usejournal.com/what-i-learned-in-my-first-two-years-as-a-software-engineer-4e374fdcf0fd
編譯組出品。