Clubhouse 在全球都掀起了一陣旋風，這股旋風也吹到了台灣的技術社群裡頭。
我們所敬愛的業界前輩保哥，就在 Clubhouse 上先後開了好幾次房間，先是討論了一個服務如果前端做了驗證，那麼後端是否還要做驗證這個話題，之後，又討論到了工程師是否應該要撰寫文件，文件其實是多麼的重要。
《工程師幹話》為了要厚顏無恥地蹭保哥的熱度，也在此提出個人的看法：一個服務無論是前端或是後端，其實都不應該驗證，而是應該把這種心力留下來認真去搞辦公室政治。至於文件嘛，如果你的工作是要發布一些 library 或是 SDK 之類的，那麼寫點 user guide 或是 reference，那總是免不了的，但如果你的工作是終端應用或是產品開發，那麼，文件，基本上就是 job security 的大敵。
如果，你在一家接案公司，幫客戶開發產品，而你寫了鉅細靡遺、超出標準的文件，客戶會付給你額外的費用嗎？會因此把關係搞得更好，所以可以繼續從客戶那裡拿到維護合約，甚至之後更多的專案呢？還是，客戶就可以照著你寫出來的文件，去尋找更廉價的乙方？
如果，你在一家新創公司，是這家公司的開發團隊元老，整個架構設計都出自你的手筆，在產品上線之後，你也把點點滴滴都紀錄到了文件當中，你預期老闆會給你什麼呢？績效獎金？配股？還是老闆就直接開除元老團隊，拿著你的文件，去找更便宜、更新鮮的肝？而且，還可能把這件事情當成他的創業成功經驗，上 Clubhouse 夸夸而談？
再換個場景，在一個稍微大一點的企業中呢，就算你寫了詳盡的文件，最後這些文件，也都沒辦法傳遞到你的理想讀者的手上，你在離職前寫了多少的交接文件，也都會湮沒在遺忘之海當中，讓想找到這份文件的人，始終找不到。
作為社畜，我們知道，如果有一位同事離職，那我們就得想辦法抹去可以證明這位前同事曾經在公司裡頭存在過的所有痕跡：如果這位前同事表現不好，那麼，他就是公司的一段黑歷史，為了要展現我們的團隊有多麼傑出多麼優秀，我們當然不會提到他；如果這位同事表現不俗，那就更麻煩了，我們平常跟其他同事競爭就夠辛苦了，如果沒事還拿出前同事的文件出來，這些文件代表的不單只是他想傳承的知識，也代表他過去的工作表現，我們把已經不在的人的表現拿出來讓人比較幹嘛呢？那可多累人啊？
沒有文件最後會如何呢？前陣子另外有個 Clubhouse 房間討論的話題，或許可以給我們一些啟發。有三個來自同一家公司的工程師開了個房間，討論他們要把公司目前的 mobile app 整個重寫，其中一大項原因是：由於公司成員來來去去，在程式碼當中有著大量過去存在，但是後來被廢棄的商業邏輯，又缺乏文件說明，後來接手的工程師看不懂既有的 codebase，那，不如整個重寫，讓產品建立在一個由現在成員打造的全新基礎上。看啊，沒有文件，產品無法維護，最後就是這樣的結果。
不過，說到成員來來去去，《工程師幹話》側面了解了一下，在這三位工程師上頭，有一位在同一家公司、同一個部門就職二十年的技術主管。
這就讓人納悶了，到底是，這三位工程師在遇到沒有文件，所以得要整個 app 重寫之前，沒有把問題 escalate 到主管那邊，從主管這二十年來的經驗中解惑？還是主管看到了部屬都要出去大談他們缺乏文件的困境，也不願意在專業以及產品知識上出手相助？還是說，在這位主管的帶領下，他也沒有文件與經驗可以給部屬，而部屬還跑出去在 Clubhouse 大聲嚷嚷？這到底是什麼情況？
不管是哪種情況，看來該有文件的人就是沒有文件，在主管位置上的人，還是繼續妥妥的在主管位置上。沒事的，有沒有文件都是沒事的。工程師應該要放心大膽的不寫文件。
