從糟糕的 Onboarding 開始

當你作為 senior engineer 開始 onboard 一家新公司的時候，你會做什麼準備呢？

如果是 inhouse 的話，可能水杯跟趁手的鍵盤都很重要。

但是身為軟體工程師，不論是不是要進公司，首先開始接觸工作的第一關應該都是開發環境建立。這個環境可能是熟悉或不熟悉的作業系統、程式語言所需。

瞎子摸象的過程中，如果有一份建立環境的指南文件，那就是再好不過的事情了。

第一印象#

關於這個文件，開始閱讀時你第一個會注意到的是什麼呢？
是內文的排序邏輯還是環境需求呢？

我的話，則是先從內文排序邏輯判斷起。

那份文件的標題看起來輕重程度不一致，也許是執筆人缺乏引導讀者的概念，或者更糟的是不在意讀者，專注在自己想寫的事情。
此外，也許是團隊沒有 review document 的習慣，不然應該會有一些調整，起碼把 Heading 1–3 的基本排序做好。

這些對那時候的我來說，無疑是一個 red flag。

為什麼排序邏輯重要？
因為我想——會寫文件的人不見得是資深工程師，但有很高的機率是代表掌握了特定領域知識並被信賴落於文件的對象。

然而，這樣的人有可能不在意讀者，那就有可能不在意未來的同事如何協作。而這個團隊卻接受這樣的現況，不論 manager 或 member 多優異，這都對我來說是一個值得留意的變數，未來的合作恐怕又多了一些需要評估的項目。

保持著存疑之心，我繼續處理環境建置，直到安裝 docker 作為開發環境這一步，我卡住了。

作為前端工程師，覺得在前後端分離且有內部的開發環境下，需要在 local 建立後端環境有點奇怪。不過作為團隊的新成員，不確定是否是自己的問題也是正常的。

所以我先訂了 2 個小時當作時間的預算，在過程中邊修邊 cc 當時的 Engineer Manager（也是我後來的萬年老闆 R）。在我建置完後端環境、順手幫忙把後端 onboarding 的文件修好後，我收到消息——現在前端多數不用在 local 處理後端的開發環境，是文件忘記更新了。

如果是你，請問你會怎麼反應呢？

是沒差吧，反正環境也建立好了可以開始投入開發了。
還是在心裡劃叉叉，對團隊的 onboard 流程比個 👎
抑或是這個流程真爛，但是我來處理吧？

我選擇了最後一個。
也許是我可能真的比較拗直，誰叫這次 onboard 的經驗比上一份工作還卡呢。

前間公司因為專案技術選擇，真的需要建立前後端開發環境在 local 才能開發。
而我在多了兩年的經驗後還卡成這樣，我想我是有點不滿意的，不論是對團隊還是自己。

雖然我當時主要是做產品開發，不過我還是主動提出希望利用一些閒暇的時間修訂文件，增進易讀性及可用性，消滅這種需要看完全部步驟才知道哪些是必要的窘境，以及不同文件重複性與行文順序不符合相依性的尷尬情況。

我當時就是單純想著改善這個不舒服的狀態，對 R 做了簡單的更新提案。

他也丟了一些問題來進一步詢問易讀性問題及未來呈現的預期。這兩個問題也是在這件事情中我獲得的寶貴學習：要人買單，得先讓人理解行為背後的原因。

因此我補充提案背景，也提供說明新的結構設計原因。
後續找了一些空檔把文件如提案修訂完之後，身為社會勞工的我就回到原本的開發日程中繼續工作。

直到五個月後又有新的同事入職前，R 請我負責確認環境建置的文件。
我主動邀請幾位同事審核文件後，大家隨口提到覺得：
project structure 跟 coding guideline 都比較破舊了，不知道可不可以一併調整？

接下來的你，會答應嗎？
我想我會答應的原因，是我想在整理的過程中找到更多需要跟團隊討論的題目。
這些題目源自於開發時感受的冗餘與不確定。

因此逐項文件更新的歷程裡，我走過了以下的路：

走到後來才知道，對於不確定感擺脫的推進，是我能發揮個人特質在團隊中最大的超能力呢。

但是那時，我想——誰知道呢？