這篇其實算是
https://eclair.nagatoyuki.org/conseil/res/30531.html的後續。
真的對自己頗絕望，
好好的假日整天在想工作的東西。
還泡澡泡到一半突然頓悟。
一年多前，踏入現在這間小公司，
是在可以算最糟糕的時候進來，
系統驗收前，公司主力跑光光，
剩一個從老闆從出社會帶到大的，人很NICE的學長。
下面簡稱N學長。
然後一年多下來，好不容易慢慢把事情穩定下來。
事情做得好也有受到一定程度的獎勵。
覺得老闆的表現還算可以，難得可以遇到一個對技術比較開明的。
整間公司也有一些技術上往前進的想法。
雖然聽說N學長跟跑掉的人處的不太愉快，
不過那應該是前人的問題吧，畢竟各種資訊交叉比對下來，
「發生那種狀況，該走人的應該是N學長啊。」
怎麼會變成其他人走掉呢？想必是前人的問題比較大吧。
畢竟N學長算是公司中罕見會想要改片的開明派，
這種年輕人想進步老年人不想，最後年輕人被貼抗壓力差之類的標籤負氣走人的狀況
早就在各大社群看到爛掉。在這裡居然是反過來的，
好像可以待待看。
不過幾年下來，發現真相遠遠不只如此。
客戶提出要修改一個很久沒動的系統，這個客戶平常是N學長負責，不過我被指派支援。
老闆特別交代「要接受N的指揮」。
N卻沒有遲遲沒有找我討論要怎麼做，去跟老闆問，還得到「如果其實是N不想鳥你呢？」這樣的回答。
最後靠著熱臉貼冷屁股，搞到我自己快變成PM才終於搞清楚N根本沒花時間在這個案子上，
月底要交付，結果你現在快月中你連具體要修改位置都搞不清楚。
最後是付出我自己的客戶Delay一兩天被老闆罵的代價才把最關鍵部分改好上去。
又過了一陣子，那個系統還沒上線。我再去看系統的原始碼，發現裡面被大改一輪。
找學長討論，卻說「因為之前那個寫法實在太爛，所以我就改掉了」這樣的回應。
而且實際上這也不是N第一次這樣幹，我手上其中一個客戶的程式碼就是被魔改造過的。
自己都搞不清楚自己在寫甚麼，問問題也都只得到大概在哪邊的回覆。攤開程式碼，
裡面是一整道馬其諾防線，錯綜複雜的變數轉傳、沒有意義的變數命名，層層堆疊有如洋蔥一般。
而且結構還不固定。
好吧，你行你上。反正你負責。
附帶一提，這件事發生的時間點已經是這個預定交付日幾個月之後。
接著，有另一個很久沒動的系統，因為客戶端換新伺服器，要把二十年沒動的程式碼升級上去。
在升級過程中，有一個關鍵函式庫出現不支援新環境的現象，必須更換，
但新版本的API有小幅度改變，
需要額外檢查、重新讀API。老闆把N叫過來問說這樣改造會不會很複雜很大。
N的回答是「這要看影響範圍而定，如果這樣改造會很複雜，那就不要動手直接用舊的，如果不會的話，那就可以。」
老闆表示OK，那就不動。
老兄，人家找你來就是要問會不會很複雜，你把問題拋回去是怎樣。還給過是怎樣？
後來，有一天聽到隔壁的工程師跟另一組的老大抱怨說另一個
外援的工程師不幫忙事情做不下去，應該怎樣怎樣。
另一組的老大卻表示「面對個人跟組織的衝突時，我會優先選擇組織。」
這下我隱約有感覺到奇怪。
直到連假中某天洗澡時才突然發現，原來所謂的用人惟親就是這樣。
說甚麼個人跟組織，說穿了就是熟跟不熟。
之前說了一大堆我還沒有證明我的技術，說穿了就是自己大小眼沒自覺。
熟人用問題回答問題都可以濾鏡濾過去。對我這邊就東挑西揀挑毛病挑到程式風格，
初期還以為是對技術有概念可以挑比較細，其實只是在挑毛病罷了。
仔細一看才發現，老闆跟組長信任的技術來源，就是那堆能跟他們一起喝酒，
一起講噁心笑話的人。技術怎樣，聽他們開會就知道。
也難怪會把人氣走，連結案獎金都不要。絕望啊。