文科轉職工程師兩年,我真實感受到的優勢、劣勢,以及如何克服

優勢可以把握、劣勢可以克服

Judy Tsai
11 min readMar 14, 2024

如果你去 google 搜尋「轉職工程師」,不費吹灰之力就能得到一堆資訊,多到看不完。但內容很多著重在「如何轉職」這類方法論、或是「轉職前該考量什麼」這類由第三人稱寫的分析文。至於第一人稱視角撰寫的真實心得,多也集中在剛轉職成功不久的人分享轉職過程,看似苦盡甘來,但那些人後來過得還好嗎?做得還順利,又或是在哪裡碰壁了呢?

取之於社群、用之於社群,剛好本人轉職 iOS 工程師快要兩年半,希望能分享一些真實觀察,當作給自己的紀錄,也回饋給需要的人。

先簡短介紹我的背景:師大教育、輔系英語。大學曾自學過 UI/UX 100 天。實習與正職前後做過一年行銷,後來報名資策會課程加上自學,成功上架自己的 app 並於 2021.10 轉職為 iOS 工程師,業餘也接案。

有關我如何決定從行銷轉職為 iOS 工程師的思考脈絡,不是本篇討論的重點,如有興趣請見文末連結。

切入正題。身為從小一路讀社會組,喜愛文學,20 幾歲還在引用一些國小背過的成語和古文(有時自己都覺得很 nerd)的我,轉職工程師之後,確實因為文科的成長背景而體驗到一些優勢與劣勢,以下就我個人觀點分別說明,其中多少與我本身獨特經歷有關,請斟酌參考:

相對優勢

  • 溝通表達與換位思考

大學讀的科系,比起考試更多的是報告,書面或口頭、個人或團體都有。因此無形中累積了閱讀文獻和文字表達能力,也在小組討論和口頭簡報中培養了溝通表達、抓重點的能力,但因為當時浸泡在這種環境,不覺得自己的表達能力特別出色。

轉職後,開始認識到一些其他工程師,漸漸發現對有些人來說要寫程式沒問題,但叫他解釋就比較吃力,倒也不是不願解釋,但就是講不太清楚、不知從何說起,或是忽略對方背景知識,講了只有自己懂的東西。也許對他們而言,要「把想在心裡的概念用文字輸出」是相對生疏的。我自己則比較沒有遇到這類問題,才發現以前讀的科系號稱報告系,不是叫假的。

另外,也因為自身的文科背景,再加上碰過一點 UI/UX,也讓我在與不懂程式的同事(例如 PM 或設計師)溝通時,能站在他們的角度思考,用他們能聽懂的話、比喻來說明。

當時上架的 app,UI/UX 設計也一手包辦
  • 文獻閱讀與文件撰寫

雖然我的資歷還很淺,但我確實觀察到有些工程師不太喜歡或擅長寫文件,寫得很省話,或是字很多卻不太重視排版(半形後面請加空格謝謝),讓人閱讀起來比較辛苦。偏偏程式常常無法一目了然,又很需要文件。我看過一張梗圖實在很好笑又貼切:

接手別人的 code 已經有技術債要背,如果他又不寫文件或註解,實在是心裡苦呀

可能有人覺得寫文件很麻煩,認為自己被雇用就是要寫 code 發揮技術能力,而非行政雜務,我卻覺得寫文件蠻療癒的!因為寫 code 本身是一個很發散的過程,寫文件則是把發散過的東西收斂起來,整理成可被他人閱讀、理解的脈絡。每次把複雜的程式概念、架構用文字整理出來,就覺得很有成就感,如果能被人看懂,心裡更滿足。因為可被閱讀,才能有討論空間;有討論空間,就給了自己進步的機會。

至於閱讀文件,也算是工程師日常之一(常要讀英文官方文件)。我不確定其他工程師排不排斥,但至少我在大學修過研究方法,受過文獻探討的折磨,似乎也對於閱讀文件養出了一定程度的耐性,能耐著性子從文字海中找到與自己被交付的任務相關的敘述。

  • 履歷設計與個人行銷

受益於大學修過行銷課、一年的行銷工作經驗,讓我在求職時,通常比較無需煩惱如何包裝自己。因為求職本身也是一種行銷,只是換把自己當作產品,此時過往的行銷思維幫助我 highlight 出產品亮點(工作經歷)、對照 TA 的需求(job description)並打造連結,先明白自己的優勢、劣勢,才有辦法在履歷、面試、甚至與獵頭的溝通上盡量強調優勢能發揮的部分。

相對劣勢

  • 較高的學習成本

根據個人觀察,剛到一間公司 on board 不久時,那些聽得霧煞煞的東西,範圍由廣到窄,主要分為四大類:

  1. Domain Knowledge:關於所屬產業的知識和 know-how,例如公司在這個生態系中扮演什麼角色、和誰競爭、和誰合作、賺誰的錢
  2. 職能內的共通語言或常識:例如一樣是工程師,就算不是前端,也聽得懂 html、css 是什麼、就算不是後端,也摸過幾個 SQL 語法。另像是 http request、git 、資料結構、加解密方法,也都多少聽過、能彼此溝通。以及像是軟體設計上比較 high level 的用語,如 interface、system、component、module
  3. 公司內部商業邏輯:隨著公司產品不同,發展出的專屬用語、邏輯和定義,以軟體來說就像是運動產業的 workout session、廣告產業的 ad session,一次多久、什麼時候 start、finish,得看產品定義
  4. 自身職位的知識:自己所負責工作內容的相關知識,以 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)。公司內部社團、讀書會也是個選項,有時還可以認識不同部門的高手同事。

Photo by ThisisEngineering RAEng on Unsplash

結語

有些人萌生轉職工程師的念頭,是先被薪水吸引,也沒什麼問題,就像交男女朋友,一開始被外表吸引是人之常情,但是若想跟這個人長遠發展、認真經營關係,總得要從個性、內涵來判斷自己是否喜歡與適合。

轉職成為工程師之後,我明顯覺得喜歡的地方是只要做正確的邏輯判斷,不太會受到他人主觀意識影響,比較少勾心鬥角的政治問題。也因為這個行業隨時都有新的技術 release,大家對於學習、分享比較大方和謙虛,也能用比較開放的心胸面對未知,不會因為你沒學過某技術就因此看輕你的能力和價值。另外工作地點相對彈性、相對有機會與跨國團隊合作,也是吸引我的地方。

然而隨著寫 code 越久,越來越有大腦和電腦融為一體的現象,用 if / else、switch case 思考事情(有時不小心卡在 main thread 就會看起來當機),雖然有邏輯是好的,但人生中存在很多領域不像程式碼非黑即白,像是文學、藝術、音樂、戲劇、美感、信仰、情緒、人際關係,很多時候正是這些無法被量化、被解釋、用統一標準來判斷的事物,為我們帶來快樂、滋養著生活,讓人之所以是人,不是電腦。

至於身份認同,其實就像吃割包得要肥瘦各半才是黃金比例,文科、理科也如此並存在我裡面,甚至如果可以的話,我不太希望只因為學制這樣分,就把人分為兩種,不該讓社會的分類方式侷限了存在每個人裡面的獨特天賦。

好像有點扯遠了。

到底什麼是「成功」轉職?成功得到那張名片固然可喜,但就我看來也許只是成功轉職的第一步。優勢可以把握、劣勢可以克服,重點是做得下去、自己也喜歡,才比較接近我心目中成功的定義,而關於如何提升技術能力、行銷自己,其實網路都查得到。

關於我的轉職歷程:

感謝閱讀!歡迎各方討論、交流,可以直接留言或透過 email 聯繫到我:sonic8776@gmail.com

--

--

Judy Tsai

iOS developer。大學讀教育、畢業後做過行銷工作,再轉職為工程師。文科的心、理科的腦,相信人生有無限可能,謹慎做出大膽的決定。Email:sonic8776@gmail.com