【學長姊帶路】文科轉職工程師兩年後的工作心路歷程
原標《文科轉職工程師兩年，我真實感受到的優勢、劣勢，以及如何克服》
文/Judy Tsai
如果你去 google 搜尋「轉職工程師」，不費吹灰之力就能得到一堆資訊，多到看不完。但內容很多著重在「如何轉職」這類方法論、或是「轉職前該考量什麼」這類由第三人稱寫的分析文。至於第一人稱視角撰寫的真實心得，多也集中在剛轉職成功不久的人分享轉職過程，看似苦盡甘來，但那些人後來過得還好嗎？做得還順利，又或是在哪裡碰壁了呢？
取之於社群、用之於社群，剛好本人轉職 iOS 工程師快要兩年半，希望能分享一些真實觀察，當作給自己的紀錄，也回饋給需要的人。
先簡短介紹我的背景：師大教育、輔系英語。大學曾自學過 UI/UX 100 天。實習與正職前後做過一年行銷，後來報名資策會課程加上自學，成功上架自己的 app 並於 2021.10 轉職為 iOS 工程師，業餘也接案。
有關我如何決定從行銷轉職為 iOS 工程師的思考脈絡，不是本篇討論的重點，如有興趣請見文末連結。
切入正題。身為從小一路讀社會組，喜愛文學，20 幾歲還在引用一些國小背過的成語和古文（有時自己都覺得很 nerd）的我，轉職工程師之後，確實因為文科的成長背景而體驗到一些優勢與劣勢，以下就我個人觀點分別說明，其中多少與我本身獨特經歷有關，請斟酌參考：
相對優勢
- 溝通表達與換位思考
大學讀的科系，比起考試更多的是報告，書面或口頭、個人或團體都有。因此無形中累積了閱讀文獻和文字表達能力，也在小組討論和口頭簡報中培養了溝通表達、抓重點的能力，但因為當時浸泡在這種環境，不覺得自己的表達能力特別出色。
轉職後，開始認識到一些其他工程師，漸漸發現對有些人來說要寫程式沒問題，但叫他解釋就比較吃力，倒也不是不願解釋，但就是講不太清楚、不知從何說起，或是忽略對方背景知識，講了只有自己懂的東西。也許對他們而言，要「把想在心裡的概念用文字輸出」是相對生疏的。我自己則比較沒有遇到這類問題，才發現以前讀的科系號稱報告系，不是叫假的。
另外，也因為自身的文科背景，再加上碰過一點 UI/UX，也讓我在與不懂程式的同事（例如 PM 或設計師）溝通時，能站在他們的角度思考，用他們能聽懂的話、比喻來說明。
- 文獻閱讀與文件撰寫
雖然我的資歷還很淺，但我確實觀察到有些工程師不太喜歡或擅長寫文件，寫得很省話，或是字很多卻不太重視排版（半形後面請加空格謝謝），讓人閱讀起來比較辛苦。偏偏程式常常無法一目了然，又很需要文件。我看過一張梗圖實在很好笑又貼切：
可能有人覺得寫文件很麻煩，認為自己被雇用就是要寫 code 發揮技術能力，而非行政雜務，我卻覺得寫文件蠻療癒的！因為寫 code 本身是一個很發散的過程，寫文件則是把發散過的東西收斂起來，整理成可被他人閱讀、理解的脈絡。每次把複雜的程式概念、架構用文字整理出來，就覺得很有成就感，如果能被人看懂，心裡更滿足。因為可被閱讀，才能有討論空間；有討論空間，就給了自己進步的機會。
至於閱讀文件，也算是工程師日常之一（常要讀英文官方文件）。我不確定其他工程師排不排斥，但至少我在大學修過研究方法，受過文獻探討的折磨，似乎也對於閱讀文件養出了一定程度的耐性，能耐著性子從文字海中找到與自己被交付的任務相關的敘述。
- 履歷設計與個人行銷
受益於大學修過行銷課、一年的行銷工作經驗，讓我在求職時，通常比較無需煩惱如何包裝自己。因為求職本身也是一種行銷，只是換把自己當作產品，此時過往的行銷思維幫助我 highlight 出產品亮點（工作經歷）、對照 TA 的需求（job description）並打造連結，先明白自己的優勢、劣勢，才有辦法在履歷、面試、甚至與獵頭的溝通上盡量強調優勢能發揮的部分。
相對劣勢
- 較高的學習成本
根據個人觀察，剛到一間公司 on board 不久時，那些聽得霧煞煞的東西，範圍由廣到窄，主要分為四大類：
- Domain Knowledge：關於所屬產業的知識和 know-how，例如公司在這個生態系中扮演什麼角色、和誰競爭、和誰合作、賺誰的錢
- 職能內的共通語言或常識：例如一樣是工程師，就算不是前端，也聽得懂 html、css 是什麼、就算不是後端，也摸過幾個 SQL 語法。另像是 http request、git 、資料結構、加解密方法，也都多少聽過、能彼此溝通。以及像是軟體設計上比較 high level 的用語，如 interface、system、component、module
- 公司內部商業邏輯：隨著公司產品不同，發展出的專屬用語、邏輯和定義，以軟體來說就像是運動產業的 workout session、廣告產業的 ad session，一次多久、什麼時候 start、finish，得看產品定義
- 自身職位的知識：自己所負責工作內容的相關知識，以 iOS 工程師來說就像是 Swift / Objective-C 程式語言特性、view controller life cycle、iOS 原生的 framework 等等
以上四類是我認為無論是否為轉職者，在職涯前期剛開始一份新工作時都多少會需要時間消化吸收的知識。
身為轉職者，和相同資歷的非轉職者比起來，在 1、3 程度通常平起平坐，畢竟大家都沒在這間公司工作過，但在 2、4 的背景知識可能會是個硬傷，一般人也許只有 1、3 聽不懂，但你卻是 1 ~ 4 都聽不太懂，而這四類資訊會交錯混雜出現在你的工作日常中：在同事討論時、前輩教你時、主管交代事情、老闆報告時，讓你思緒打結、不知該從何問起，甚至可能你也發問了，但別人的解釋又再度混雜了這四種資訊，有聽沒有懂，又不好意思麻煩他花太多時間解釋，最後很可能就這樣矇混過去了。當這樣的矇混與你實際做的工項相關，情況就變得棘手，因為你也不知道自己的問題在哪裡，等到被同事、甚至客戶發現都不知道什麼時候了。
如何克服
針對這種狀況，我個人的建議是：從 4 到 1 的順序逐步學習。1 和 2 屬於比較廣泛的 sense，要不是無法在短時間吸收，就是無法立即應用在工作上。3 也是需要一段時間慢慢熟悉，但 4 可以透過即時詢問前輩、自己 trace code、上網直接查官方文件、Stack Overflow、甚至問 AI 等方式，在相對短的時間內掌握，並落實在工作中。在 4 掌握度還不高的時期，我認為 1~3 不懂的地方可以暫時先擱著，只要在改 code 時注意一下，如果和 3 有關的邏輯，要先和前輩或主管確認過再交付出去。例如你以前完全沒碰過藍牙，但這間公司產品會用到，那可能要先主力研究 iOS 原生的 CoreBluetooth 框架，了解一個 iOS app 如何掃描附近的藍牙裝置，至於當 app 掃描到藍牙裝置時該做什麼處理，就和商業邏輯有關，要謹慎修改。
3 和 4 已經熟悉之後，通常也待了一陣子，和同事有過一些溝通經驗，此時可以多留心同事常講的那幾個你總是聽不懂的用語，開始往 2 去涉獵。例如我 Android 同事提到的 abstract class 在我使用的 Swift 語言沒有，查了才發現 Java 有這個東西，對應到 Swift 比較像 Protocol；前端同事常常提到的 iframe、vue.js 雖然好像是常識，但由於和我工作沒有直接關聯，也是晚點再去探究即可。
最後關於 1，雖然在面試和新人訓練時一定會聽到，但可能只是講個大概，或即便講得很細，也受到其他知識不足影響而一知半解、聽過就忘，但就算解釋不出來，也不至於影響到工程師的日常工作。我個人是覺得可以平時寫 code 寫累了，查查相關公司文件、文章來補知識，順便轉換心情。或是直接勇敢跟前輩、主管約個 meeting、借個會議室來請教，在 2~4（特別是 3）都熟悉了之後再來鑽研 1，會有種看見新天地、終於開竅的感覺。
- 溝通抗壓性
受到文科教育的薰陶，再加上大學科系以「教育愛」自豪、好歹也讀過一些輔導，以前都覺得說話要用「三明治溝通法」，前後用好話包裝，中間才放自己想給的建議，以顧及對方的感受。殊不知理組的世界是丟掉麵包，直接吃肉，根本不知道有三明治這種食物。剛開始可能會不太適應同事較為直接的說話方式，擔心他這樣說話會不會是討厭自己。
其實工程師這個職位，本來就被期待說話精確、客觀、比起其他職位更不帶情緒就事論事，有一說一。你能想像這種對話有多恐怖嗎：
PM：「我們目前線上的 app 產品，有辦法新增支援 XXX 功能嗎？」
工程師：「嗯⋯⋯我想應該不是沒辦法。」
有就說有、沒有就說沒有、不確定就說自己需要一點時間確認，但最後的答案也會聚焦在有或沒有，頂多附上幾句說明。工程師說話如果太委婉迂迴，反而會被覺得對自己的程式掌握不足，有失專業。
如何克服
只要持續浸泡在這樣的環境，自然就會克服了，就像泡在全英文的環境，英文要不變好也難。告訴自己，對方這樣說話是針對事情、不是針對你，不要往心裡去、不要玻璃心。其實工程師寫 code 久了，自己的大腦思維也越來越像程式 function，遇到 error 就要 throw 出來，轉換成中文就是講出來跟你討論，要他忍住不講搞不好更痛苦，然後就 crash 了（笑）。
不只習慣，甚至自己也會逐漸變成這樣的人。在我轉職後，竟然被文科、理科出身的朋友一致認為比較像理科女生，理由是比較理性、講話「比較直接」，這是我在讀社會組時不曾收到的回饋，想想也是頗有趣，到底是我變了，還是以前都在忍耐？
- 人脈資源
轉職的人需要靠大量時間自學，通常很少同儕，就算有也是轉職班、coding bootcamp 認識的同學，大家也都不是資訊背景，因此需要重新開始累積這方面的人脈，就會比本科生相對吃虧。畢竟許多資訊、資源都是透過人脈流動分享，例如內推機會、面試或工作心得與情報、研討會或活動資訊、接案機會、side project 合作機會等等。
如何克服
首先從公司內部同事開始打好關係，盡量多認識其他工程師或資訊技術人員，不用侷限他是寫什麼的，app、前端、後端、資料分析，也可以往外結識相關職位的人，例如 PM、UI/UX 設計師、QA 人員，並不是指要別有用心去攀附關係、硬尬聊，其實只要抱著友好的態度、學習請教的心態，在有機會互動的時候釋出善意即是好的開始，不要想著對方要給自己什麼好處，當作交個朋友就可以了，機會自然會在對的時機點找上門。
如果要更上進的話，還可以參加一些社群活動，例如 iOS 工程師的 Cocoaheads 每月聚會、或是參與技術研討會，以 iOS 來說在台灣可以參加 MOPCON 行動科技年會、iPlayground（雖然近年停辦 QQ）。公司內部社團、讀書會也是個選項，有時還可以認識不同部門的高手同事。
結語
有些人萌生轉職工程師的念頭，是先被薪水吸引，也沒什麼問題，就像交男女朋友，一開始被外表吸引是人之常情，但是若想跟這個人長遠發展、認真經營關係，總得要從個性、內涵來判斷自己是否喜歡與適合。
轉職成為工程師之後，我明顯覺得喜歡的地方是只要做正確的邏輯判斷，不太會受到他人主觀意識影響，比較少勾心鬥角的政治問題。也因為這個行業隨時都有新的技術 release，大家對於學習、分享比較大方和謙虛，也能用比較開放的心胸面對未知，不會因為你沒學過某技術就因此看輕你的能力和價值。另外工作地點相對彈性、相對有機會與跨國團隊合作，也是吸引我的地方。
然而隨著寫 code 越久，越來越有大腦和電腦融為一體的現象，用 if / else、switch case 思考事情（有時不小心卡在 main thread 就會看起來當機），雖然有邏輯是好的，但人生中存在很多領域不像程式碼非黑即白，像是文學、藝術、音樂、戲劇、美感、信仰、情緒、人際關係，很多時候正是這些無法被量化、被解釋、用統一標準來判斷的事物，為我們帶來快樂、滋養著生活，讓人之所以是人，不是電腦。
至於身份認同，其實就像吃割包得要肥瘦各半才是黃金比例，文科、理科也如此並存在我裡面，甚至如果可以的話，我不太希望只因為學制這樣分，就把人分為兩種，不該讓社會的分類方式侷限了存在每個人裡面的獨特天賦。
好像有點扯遠了。
到底什麼是「成功」轉職？成功得到那張名片固然可喜，但就我看來也許只是成功轉職的第一步。優勢可以把握、劣勢可以克服，重點是做得下去、自己也喜歡，才比較接近我心目中成功的定義，而關於如何提升技術能力、行銷自己，其實網路都查得到。
文由 Judy Tsai 授權轉載, 原文:《文科轉職工程師兩年，我真實感受到的優勢、劣勢，以及如何克服》
___________
你也有經驗想分享嗎？快來投稿賺稿費吧！
瀏覽 1,098 次
