嗯,這算是我的第一份真正工作,但我還是沒習慣為了早上 6:30 的班表起床……我已經這樣做了好幾個月了,照理說到現在我的身體應該早就接受我其實是個晨型人了。
但沒有。
老實說,早起甚至都不是這份工作最難的部分。真正難的是我一到公司之後發生的所有事情。
我加入現在的公司時,對人生第一份工程師工作有個很簡單的想像。寫程式、學新系統、犯錯、變強,或許還能碰一些酷技術,總之就是做所有我想像中軟體工程師會做的事。
很單純,輕輕鬆鬆。
但現實不是這樣,我被丟進了一家大公司;那裡的技術很舊、系統很重要,大部分工作都是支援和維護,你也不能把正式環境當成自己的小副業專案來玩。
這其實也合理,因為真的有人依賴這些系統,我想也沒人希望新人在早上 10 點突然覺得「架構如果重寫一下會更乾淨」,然後就把整套系統翻掉。

拜託不要。🥹 會有人直接在你背後現身。
我現在大部分工作都圍繞在支援既有的主機系統、維護紀錄、遵循流程,以及處理那些對隱私和資安非常嚴格的系統。
所以很少有那種我可以直接說「嗯,要不要改成這樣」然後開始改流程的時候。系統本來就已經存在了,大家也已經依賴它,而且在做某些看起來非常小的操作之前,還得先查手冊。更麻煩的是,這些操作還會從組長到駐點層層審核。
而作為新人的其中一個最奇怪的地方是,有時候我甚至不知道自己為什麼要做那個操作。
可能會有人叫我新增、刪除或更新某個值。手冊會告訴我們要檢查哪些欄位、需要滿足哪些條件,所以我們就照著做。
但我腦中總會有個小聲音在問:「好……可是這個值到底是在做什麼啦?」
它會影響什麼?為什麼一開始要加這個東西?
而很多時候答案都是:
我也不知道啊啊啊。
我不是在講這個應用程式的大方向或商業目的。我是在講那種很具體的「為什麼要改這個東西?」的原因。對工程師來說這很奇妙,因為你是照程序正確地在做事,但你不一定知道那個程序背後的理由。
我可以花好幾個小時去理解每個細節,但那也不一定實際。要學的東西已經多到荒唐了,我不能把那麼多時間花在一個「需要立刻完成」的事情上。什麼都要立刻完成。
所以我正在慢慢摸索那個平衡點。
這是我做 side project 時從來不用特別思考的事。那時候我通常非常清楚自己在做什麼、為什麼而做。如果我半夜 2 點做了一個亂七八糟的 React app,至少我知道資料庫裡為什麼有某個欄位,因為那個欄位就是我這個笨蛋自己加進去的。
在這裡就不是這樣了。
新人訓練基本上分成三個階段:KT、模擬,然後實作。
在 KT 階段,我們學系統、流程、術語,還有那些公司以為我們理所當然應該知道的東西。接著是模擬,讓我們在不真的碰正式工具的情況下把工作跑一遍。很直接。
然後到了實作階段,事情就開始有趣了,因為模擬終究只是模擬。
你可以理解步驟、照文件做、正確完成情境,但等你真的打開實際工具時,突然就冒出十個你不知道自己還要注意的小細節。
這不一定是因為訓練很差。我覺得只是「知道自己應該做什麼」跟「真的在真實系統裡做出來」是兩回事。
你可以花幾週讀 Git、理解部署、做出一個示範應用程式,諸如此類……但等真的出問題時,你才會發現教學根本沒提過那件事。
而這大概就是我最困惑的地方。我的確理解為什麼錯誤不能被直接無視。這些都是重要系統,做錯真的可能造成實際問題。
但如果你才剛從模擬轉到真的使用工具,會犯一些錯其實也是重點之一。那就是你開始知道自己哪裡不懂的方法。那也是你慢慢培養出那些之後會讓工作變輕鬆的直覺的方式。
還有另一件事我想了很久。
這個專案在我們之前的前輩,大概都有 20 年以上的經驗。
我 22 歲。嗯,快 23 了,大概一兩週後吧,但這裡故事先當我還是 22。😭
我身邊大多數人也都算年輕,團隊裡經驗最豐富的就是我們的組長。
而他當然也只有一個人。他不可能替整個團隊處理每一個技術問題、每一個故障、每一個決策和每一個溝通問題。所以有時候你真的會感受到那個經驗落差。
我們在學、我們在犯錯,同時又被期待要達到那些已經花了好幾年學會這套系統的人所設定的工作水準。
而對我來說還有另一件事,因為我還在學日文。我很多工作之外的時間都拿去把語言練好,而我在工作中也要用日文,同時還要理解工作的技術面。
所以有些時候,我不只是要弄懂系統在做什麼,還得理解別人用我還在學的語言跟我說了什麼。
這不是犯錯的藉口。如果我搞砸了,我還是得變得更好,而且有時候真的就是技術問題。

我沒有把事情理解對、我漏掉了某些東西、我做了錯誤的決定。這種事常常發生。而且我也有重複犯同樣錯誤的問題。唉,寫這段真的有點痛苦。
但我也開始學會分辨「我只是還不熟」和「我真的很不會」。
我最近開始思考的另一件事,是責任和控制權。
我們有聊到閒置工時、團隊架構、工作可用性,以及為什麼某些事情沒在發生;而有時候被質問的人,其實並不是那些真正控制那些事情的人。當然,我要對自己做的工作負責。如果我犯錯,那就是我的責任。
但我沒辦法控制有多少工作可做、團隊怎麼編制、訓練怎麼設計,或是別人到底跟另一個主管講了什麼。
你可以對自己的工作負責,但不代表你要對工作周邊的一切都負責。還有另一件事也很重要:不是每個人都在相同的配置下工作。有些質疑我們交付時間的人,手上有一些系統和工具,能讓某些操作快很多;但我們這邊用的是比較受限的配置。

嘿,我不是在說我們不需要進步啦……
如果某件事真的花我們太久,那當然要想辦法找出原因並改進。但「某個人很慢」跟「他所使用的系統很慢」之間是有差別的。這件事如果不是在大公司工作,我大概不會想得這麼多。
你工作的速度,不只是看你有多努力而已。你有什麼工具、你能存取什麼、你遵循什麼流程、以及你還依賴多少其他人,這些都很重要。
老實說,溝通本身就已經是另一種學習經驗了。管理層有好幾層、期望不同,有時候指示也不同。某個人說一套,另一個人說得稍微不一樣,你照著被告知的做,結果又有人問你為什麼要那樣做。
你會突然開始懷疑自己到底是在解技術問題,還是在玩一場超複雜的傳話遊戲。

然後還有相反的問題。
有時候溝通明明完全沒問題……只是持續的時間實在太久了。
我聽過一些說明,明明二十分鐘內就能講完,結果不知怎麼竟然花了快兩小時。
對,我為了這個還跳過午餐好幾次了。到某個時候,你不再懷疑系統是不是有瓶頸,而是開始懷疑那場會議本身是不是瓶頸。
但在這些事情底下,我開始注意到,溝通不只是資訊有沒有傳到對方那邊而已。對方有理解嗎?該聽的人有聽到嗎?這件事能不能用訊息就好,不用開兩小時的會?這些事情在我大多數的溝通都還只是 GitHub Issue、Discord 訊息,還有「嘿,可以幫我看一下這個 PR 嗎?」的時候,幾乎都沒想過。
不管我去哪裡,溝通這件事總會再次冒出來。諷刺的是,大家總是說它很重要,但到了實際執行時卻常常忽略這一點。
這真的是我認真問過自己的問題。當你一直在犯錯、一直被質疑、又看著那些有多年經驗的人把事情做得好像很輕鬆時,你很容易開始覺得,也許是自己不夠好。
我不覺得應該這樣看待這件事(至少為了我自己不要這樣想)。我們經驗不足。我們在學一個在我們加入之前就已經存在的系統,我們透過 KT、模擬和實作來學習,而且還被期待很快就要能產出成果。
有時候我回頭看某個錯誤,真的會想:「對……那次完全是我的鍋。」我不是想說服自己,每一個錯誤都是因為訓練不好、工具不好或管理不好。有時候我就是理解錯了,就是這樣。
但我也慢慢意識到,如果你真的希望別人把事情做好,你最後還是得讓他們真的去做。
你需要足夠的空間去犯錯、理解錯誤為什麼發生,然後慢慢建立出手冊給不了你的那種理解。
在這整段過程中,我也不得不承認另一件事。我其實不太喜歡這份工作的內容本身。
支援和維護不是我想像中會長期做的事。主機系統也不是我想專精的領域,而老實說,我覺得能認清這點也不是壞事。
我以前以為,如果我拿到一份軟體工程師的工作,我就會自動知道自己喜不喜歡當軟體工程師。
但你可以做產品、維護系統、做基礎設施、支援企業應用程式、處理事故、設計架構、跟客戶合作,或者就只是寫程式。
而且顯然還要凌晨四點多起床。😭
也許這就是第一份工作的其中一個好處。你不一定會馬上找到自己真正想做的事。有時候你會先發現自己絕對不想在接下來十年做什麼。這樣也算有意義吧?
有些日子我真的會懷疑自己是不是在浪費人生中的一年。即使我還是持續在學日文、在工作之外做東西,還在摸索自己職涯真正想往哪裡走。
但我也會想想,自從加入之後,我到底改變了什麼。我現在稍微更懂大公司是怎麼運作的了。我開始注意到以前可能會直接忽略的溝通問題。我明白了訓練和經驗不是同一件事,而且我也開始注意到,資深工程師其實有很多知識是幾乎不用想就知道的。離譜。我也變得比較不怕問蠢問題了。也許最重要的是,我現在更清楚自己不想在接下來十年做什麼。知道哪個方向是錯的,在你還在找路的時候其實也很有用。
我現在還不知道最後的答案是什麼,也許這是我能給這篇文章最誠實的結尾。我還在這個過程中。我還在犯錯、還在努力變好,也還在想自己到底什麼時候才會真的變成晨型人。

我現在還不知道,之後回頭看這一年時,我會想「那真是浪費時間」,還是會想「那是我學會現實世界到底怎麼運作的那一年」。
也許兩個都會是吧。但我確實知道,第一份工程師工作不一定會給你原本以為會得到的經驗。有時候它給你的會是別的東西,而你可能要過很久才會真正明白那是什麼。至少現在,我還在慢慢弄懂。
如果你已經工作一段時間了,我真的很想知道:你的工作讓你在當下沒有察覺、但後來才明白的事情是什麼。
原文出處:https://dev.to/itsugo/my-first-engineering-job-is-teaching-me-something-i-didnt-expect-l96