老菜鳥軟體工程師的新工作週記(3)

一開始進公司時就被告知，未來會隸屬在團隊中的系統架構小組下面。主要的工作職責是規劃未來新功能上線時的架構，並且以此訂出一個固定的規範，避免再發生每位開發者各自為政，讓專案變成可以動但很臃腫的狀態。

臃腫但可以動的狀態，腦中浮現的就是神隱少女中河神的畫面

跟我一起在架構小組的是Kevin，他是一個資訊背景的純血工程師，雖然年紀比我小很多，但因為畢業之後一直以來都沒有偏離跑道的關係，軟體的相關工作經驗應該是比我稍微多一點。在我還沒進來之前，這個小組有很長一段時間都是他在獨挑大樑。我還不是非常清楚做系統架構需要什麼樣的能力，也甚至還沒有完全搞清楚就系統的運作，就要開始參與後續的規劃，略微的感到有些吃力，感覺像是在毫無邊際的泥潭中走路，連談起腳步探索都需要花上不少心力。不過Kevin的純血背景加上經驗，像是泥潭底部的石頭，讓我莫名的產生安心的感覺，尤其目前有一版本的新架構專案已經實際的在測試中，我想應該可以先依照他的想法去走一段時間。

這一週大概的狀態是透過一場一場的會議去淺移默化一切的概念建立，雖然無法具體說明，但同樣的名詞對今天的我與昨天的我來說，都會有不一樣的意義存在，與久遠以前的學生時期透過固定的進度與考試學習的方式不同，這應該也是在新工作中最快速的融入方式。

開會有感

即使還只是第三週，但對於開會這件事開始有點心得，之前在做PM/業務時，因為在日系公司，開會總是曠日廢時，繞著一些很小的細節打轉，但因為公司性質的關係，與會人會很常都是各個公司的大人物，雖然一樣曠日費時，但至少討論的都是決策面的大方向，久而久之大概也可以抓出一間公司的領導層可能在意的細節是什麼。而在轉職變成一個小小的工程師後，開會的內容開始變成很實際落地的內容，能夠影響的內容已經跟決策無關，頂多只能改變專案層面的走向。

現在的會議主要討論的都是未來新開發專案的架構方向，就影響的人數來看雖然不是整個公司決策層級別，但至少會影響到一個部門的協作模式，算是介於過往經驗的中間段。扣除一般的例會，基本上是分為Paolo有加入的會議跟沒有的會議，沒有Paolo的會議算是我跟Kevin的私下討論。幾次開會下來有一種感覺，有Paolo的會議進行方式是由上而下在看事情，而與Kevin的會議則是反過來。Kevin非常注重實作面的東西，假設今天跟Paolo討論的內容是要蓋一座房子好了，Paolo會聚焦於為何要蓋這座房子，他可能需要滿足什麼要求，而會議結束後的討論上，Kevin會直接開始挑選要使用的磚塊，而不是先畫設計圖或是延續討論。但有時又讓我覺得是他心中已經有一張設計圖，只是跳過展示給我看的部分開始規劃實作而已，畢竟之前都是他一個人在處理這些事情。

會讓我產生上面感悟的主要是這週間開了一場讓我對議題聚焦方向特別有感的一次會議，在跟Kevin討論過後我們分工下去大概花了一天生出了第一份文件。並且拿這份文件去跟Paolo開會。從結論來看，雖然文件中寫了很多具體的內容，但完全沒有真正聚焦在需要解決的事情上，整份文件就像是隔靴搔癢一般，令人特別難受。難受歸難受，目前對於這樣的事情覺得還滿有趣的，雖然自己漸漸進入狀況了，但應該會一邊繼續觀察，一邊試著最低限度地提出意見來嘗試看看。

除了觀察其他人的思考習慣以外，我也在反思自己在思考議題上的問題。在跟Kevin討論時雖然會覺得他太過快速地進入實作的部分，但我發現如果由我自己來思考會陷入一種尋找標準答案的旋渦當中，我會很想要尋找一個能夠說服所有人的最優解，但因為現階段不可能知道所有的客觀條件，因此會花上很多額外的時間去做很多假設性的評估或是無意義的上網找資料，反而欠缺踏出去的那一步決定。目前思考的解決方式是先將手邊已知的資源整理出來，至少在陳述自己想法時可以有足夠的根據讓人理解思考脈絡。

最後來點題外話

這裡想來講講PR，PR是Pull request的縮寫，假設一份專案程式碼是一本書，整個團隊的大家就是共同作者，團隊的領導者像是編輯，而一本書出版後，作者（工程師）們可以對書進行任何刪改或是增加內容，只是在變動書的內容前，需要提出申請，由編輯來審核內容是否合適，沒問題的話就會將內容進行調整然後再版。PR就像是這申請的行為。而發PR這件事可以粗淺的看作工程師們平常提交成果的一部分展現。

講這麼多主要是想提到，上週提到的清洗資料庫腳本總算完成了，在這一份新的工作上總算發了第一份PR，算是以一個開發者的角度實質上有點貢獻了，可喜可賀。