對API那麼多意見不會自己學習建SQL，你高興怎麼設計就怎麼設計啊。

在跟不同領域的工程師溝通的過程中，往往會聽到要提供API的資料時最好是用多層次資料結構，且欄位名稱由提供API的人自定，只要看得懂就好，才會有比較大的彈性，但給到兩層的JSON資料且命名不是有意見的那個人的想像時，又會被說太多層了不好解，且欄位命名規則不一致。就說該由接的人來定義好和命名好RRRRRRR

開發公司內部系統 剛好最近有機會整理程式。 想到之前有幾個地方趕時間沒有接檢查框架。 所以其實是沒有權限判斷知道網址隨便打的狀況。 想說爬一下前人的權限框架怎麼接的， 趁現在補接一下。 結果， 阿★你根本沒接啊。 直接打網址進去...★還真的沒接... 所以是只要有網址就無敵的系統... 好加在是一些關鍵行為都有用身分...

我老爸不知道從哪裡撿了一台電腦回來 只因為紙箱外盒寫著黑旋風 我爸就以為是電風扇 原本想要拆開來殺肉的 一看到硬碟是IDE排線才發現 這台TM是10幾20年前的古董 直接叫我爸再拿去回收

最近幾個不同部門，能力比較 ok 的研發主管、RD，開始自己組成專案小組， 這樣才不會和原本以部門溝通的方式一樣，一直出包。然後也可以趕快結案、拿獎金。 不過 EE 主管一直搞不懂，我們 SWE 到底是什麼狀況，我只好用他的專業舉例： 想像一下，你請你的 EE 負責 PLL 電路，也手把手的教了。但是教了半年，只要有一個星...

發現同事真的強項是SA，這樣真的不考慮GraphQL嗎？把SQL都設計成GraphQL，剩下直接做指點就好，也不用再考慮API怎樣才符合畫面需求了。

老闆花了 800 萬重新裝潢辦公室，電腦和辦公家具，也都換成高級品。 所以我現在看著一群工程師，重回新辦公室後，一樣不鳥你的 code review 審查， 而是在漂漂亮亮的新辦公室，一邊用著電競等級的設備，一邊繼續拼命寫出架構和可用性，比國中生程式補習班還糟糕的程式碼，和不斷砍掉重練的專案 ... 喔對了，我可能不是來...

突然睡不著... 感覺我已經很拚命在學 AWS, Coding, 虛擬化, 資安, 備份, SA, 前端, Code review, 網路等東西了, 但時間總不夠用、永遠有新的問題、事情總是卡在不熟練、理解不夠透徹, 我是不是距離 Burnout 不遠了? 有沒有大大能分享之前都怎麼走過來的?

公司說這禮拜要讓客戶測試了 要趕快生出東西給他測 說啥一個月前就有說要弄 啊你他媽每個禮拜新需求都排滿 還每三天插個急件 你提前一年告訴我也沒用啊 洗咧幹

台式職場文化就是容易以為私人關係可以抵銷職場與工作上的錯誤；你要情緒勒索、要私底下表現得多卑微可憐我隨便你，但真的你不專業就是不專業，雷就是雷。