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

這一週是略顯平淡的一週。

有可能是因為目前對於每件事都還沒有完全的掌握，處於一個青黃不接的狀態。也有可能是因為這週是寫文件的一週，感覺工作內容並不是那麼符合一般對工程師的想像，不過也對寫文件這件事產生了一些感觸。

上一週開始實際跟著Kevin一起進入專案架構的規劃後，必要做的第一件事就是開始將規劃的構想寫成一份文件。

過去再進行專案管理的工作時，很常面對一種問題：即使雙方已經就各種可能性，將所有的約定清楚的寫在合約中，現實總是還是會發生當時沒有想像到的情境，而且實際就情境內容去尋找合約條文時，會發現寫得再清楚的內容也一定還是會有解釋空間，最終總是會造成「公說公有理，婆說婆有理」的情況。

即使是寫得很清楚的合約，在每個人讀的時候都還是會產生歧異了，一份寫得很籠統的文件也會造成開發時很大的誤解。不過基本上只要是一個工程師，很大的可能是對於「寫文件」這件事感到厭惡的。尤其是在軟體在快速迭代的過程中，一個邏輯可能在程式碼只是兩行的調整，但對於文件內容的影響不止一兩頁的情況都存在，要求一個工程師好好的將文件寫完是一件很不容易的事情。

或許因為半路出家，我對於寫文件這件事並沒有太大的排斥，相反還有點樂在其中。前陣子跟三年前轉職時的主管吃飯，他說我離職時做的交接手冊到現在都還是新人到職時第一份研讀的內容，而在上一份工作中，雖然並沒有將所有的文件補充到我覺得很完整，但至少是新加入專案的任何人都能夠透過這份文件了解所有事情的前因後果，並且很快地進入狀況的程度。

其實在剛入職時，公司也提供不少參考文件讓我可以快速的將專案執行起來或是認識公司流程。但讀起來都會有同樣的問題，對於新人來說，太多內容被因為「常識」的理由忽略了。舉例來說：文件中可能會出現這樣的內容「每星期三需要將電腦關機」 ，對於已經在公司待很久的工程師，他們可能都可以理解，或許每週三下班時間公司都會固定停電一晚（當然現實中應該不會有這麼瞎的狀況），因此需要將電腦關機來保護電腦，但對於不知道原因的其他人來說，這件事情本身是一個很無厘頭，而且沒有記憶點的規定，在閱讀的過程中其實蠻干擾整篇文章的理解。也因此，再確認過我也可以修改之後，前幾週我也會嘗試去做一些低限度的調整。

講這麼多感想其實都跟這週實際面對的問題沒什麼關係，這週面對的問題是沒有太多零碎的任務可以填補主要任務的時間差。會有這樣的感受，其實是因為這週在寫文件的時候，我自己想像的流程是：

文件調整 > 給Kevin確認 > 有問題的地方再調整 > 再確認。

來來回回幾次應該就可以把上週開會的內容整理成一份文件。

但實際上Kevin並不是只有這一件事情要處理而已，因此當改完手邊的版本，到可以進行下一次的修改之間，會有一段無法掌握的時間差。這樣的問題好像不僅僅是軟體工程師可能面對的，現在回想前幾份工作或多或少也都會有這樣的時期，在對工作的熟悉度提高後就自然會消失。不過這次我是記下來了，之後無論是換新工作或是有新人進來，應該都可以事先對這件事留上心。

撇除實際工作的內容，這週倒是有些分內工作外的事情發生。

公司的尾牙是由各部門推派人選一起規劃，當Paolo在部門的頻道上問大家有沒有人想要自願參與時，在跟身邊的同事探聽了一下過去尾牙的進行方式之後，我決定接下這項差事。

除了希望可以透過活動的規劃盡快地跟其他部門的同事變得熟悉以外，過去在前公司也曾經負責各種活動的規劃的經驗也對我的選擇產生影響。

身邊大部分的人都會覺得除了分內工作以外還要花時間去進行這些沒有額外酬勞的事情是一件吃力不討好的選擇。但對於一個熱愛規劃的J型人格的我來說，能夠按照我自己的想法去影響活動的進行本身是一件很有趣的事。過去的我很愛提一些與往年的活動不同的進行或呈現方式，期望可以讓參與的大家產生「今年的活動與往年好像不太一樣哦」的感覺。因此雖然才進公司不到一個月，但我決定還是試著接下這份工作，畢竟退一步來說，應該沒有人比新進公司的菜鳥還要閒了吧，這也是個很適合用來填補分內工作之間空閒時光的任務呢。