身為一名資歷深厚的程式設計師，究竟會洞察到哪些職場真諦與生存要訣呢？
GrumpyOldDev，是一位開發者給自己和網站取的網名，他是一位在金融服務領域深耕的技術人，早期從他父親將 Apple II 電腦帶回家時起，他就對科技深深著迷。據他所言，若是居住在美國進行信用卡或借記卡交易的人，極有可能與他 在幕後 所設計和推出的軟體產生過互動。
在職場中，恰如這位開發者給自己取的網名含義一樣，他是個脾氣略顯暴躁的老開發者。就在近日，他在分享自己職業生涯故事時釋出了一篇名為【The One Where I Lie To The CTO】（我對 CTO 撒謊的情況）的文章，在 HN 上引起關註，其中他所闡述的職場生存法則引發了部份開發者的強烈共鳴，不過其做事方式也存在一定爭議。
接下來，我們就來看看他在開發工作中如何上面對 CTO、外面對客戶以及內對接外包公司的。
原文：https://grumpyolddev.com/post/the-one-where-i-lie-to-the-cto/
編譯 | 蘇宓
出品 | CSDN（ID：CSDNnews）
以下為譯文：
這是幾年前的事情了。要知道，在我職業生涯的早期，父親曾告訴我，做好工作往往意味著不顧老板的反對，做該做的事。他的意思是，你要麽可以讓你的老板成功並快樂；要麽你執行老板的每一個決定，在這種情況下，沒有人會感到成功或快樂。
當時，我在一家財富 500 強公司工作，我們的 CTO 和一個重要客戶簽約了一個大計畫，他與這名客戶有私人關系。此外，他還決定將計畫中的一個關鍵部份外包給一家大型科技技術服務公司來完成，這家公司聲稱他們有一種產品可以為我們完成大部份繁重的工作。
不靠譜的外包
在我的職業生涯中，當外包供應商公司說他們有一個產品時，他們真正的意思是他們有一個隱約類似於產品的東西，隱約符合我們的需求，透過大量的客製，他們可以把它變成我們需要的東西。
當然，透過客製他們的「產品」，我們巧妙地將供應商軟體的所有缺點與客製軟體的所有缺點都結合在了一起。我們同時實作了「壞主意」中的「聖杯」： 一個不靈活的供應商軟體包，它必須被迫去做一些它本來不應該做的事情，而且還要從他們的主產品程式碼庫中分叉出來——一旦供應商意識到維護它的成本有多高，它遲早會被淘汰。
作為開發人員，我們內部互相吐槽這是一個多麽可怕的餿主意，尤其是考慮到過去外包開發公司往往不會按時交付產品。
然而，因為我們的 CTO 每年都會更換他的直接下屬，所以每次他的下屬向他匯報有關計畫的狀態電話都是「老板，這是個好主意」，盡管實際上根本沒有人認為這是一個好主意， 甚至從心裏認為這是一個平庸的想法亦或是個壞主意。
錯誤開始
計畫的其他部份都需要在公司內 部進行大量開發，所以我們也有自己忙碌的事情和種種挑戰，忙得不可開交。但即便如此，隨著整個夏天計畫日期的推遲，外包供應商承諾他們的產品可以在 10 月份釋出日期之前隨時整合過來，然而除了 CTO 之外，其他人都越來越明顯地感覺到計畫遇到了麻煩。
終於在八月份，外包供應商交付了他們的「產品」，我們開始了與之「整合」的死亡之旅。
九月份，我們遇到了一個令人窒息的錯誤：
外包供應商 的產品將每筆客戶交易作為 json 記錄儲存在一個巨大的 json 文件中。
因此，隨著測試數據的積累，產品的效能變得越來越慢。它的原理大致是：添加一個新的交易需要從資料庫中讀取整個 json 文件，然後將新記錄添加到文件末尾。
外包供應商聲稱，他們可以透過對交易欄位進行索引來解決這個問題，這似乎有點幫助，直到我們遇到了第二個問題。
他們選擇的資料庫是 MongoDB，而當時 Mongo 的記錄限制是每個文件只有 16MB。
因此，到了 10 月份，當轉換團隊開始將真實的客戶數據放入其中時， 我們開始遇到 16MB 的限制，事情發生了非常有趣的轉變。
隱瞞與真相
我們決定向客戶隱瞞這一限制，並推遲一個月上線，但同時啟動了一個Skunkworks 計畫（秘密研發的計畫）來替換外包供應商開發的功能，而且也沒有告訴供應商。 因此，我們同時欺騙了客戶和重要的技術合作夥伴。
當時，GrumpyOldDev 組建了自己的團隊來構建替代方案。供應商在這個計畫上大概有 70 個人參與。GrumpyOldDev 指派了 3 個人來開發功能替換它：
一個負責設計資料庫；
一個負責構建與資料庫介面的後端；
還有一個負責構建業務邏輯/網路服務。
客戶被告知，我們將在一月份推出新版本供他們測試。新版本將修復他們在最初上線時接受的最關鍵缺陷，但他們並不知道 我們要重寫整個核心系統。
此時距離新約定的交付時間只有不到兩個月的時間。而最初的計畫啟動卻花費了一年多的時間。我們只有 3 個人，而供應商那邊卻有 70 個人。更關鍵的是，3 個人還是只利用了假期的時間。
因此，大約在 12 月中旬，所有參與計畫的人都被告知（不是要求）要在假期中工作。
要知道，在過去的 6 個月裏，我們中的大多數人已經每周工作 60-80 個小時，只為趕上原定的釋出日期。 每個人都累壞了。
此時此刻，如果你是一名開發者，且不是一個以交付為導向的技術人員，你可能會覺得這太瘋狂了，是時候辭職了。
或許你是對的。
但，我們中很多真正喜歡軟體開發的人都覺得自己有點像搖滾明星。你花了幾個月甚至幾年的時間來準備這場演出，然後你的釋出日期就像一場真正的表演，大家都想在釋出日期一炮而紅。
其中部份原因就像劇院裏的人：演出必須繼續。但你也希望當你所有的辛勤工作第一次觸及真實使用者，並且你感受到那種「我做到了」的興奮時，覺得自己像個搖滾明星。
那時的使用者喜歡我做的事情。我戰勝了不可能。對於內向的人來說，軟體釋出就像是現場表演。
所以，這個時候差不多快到聖誕節了。團隊基本上用一個月的時間就完成了替換軟體的工作。只不過還有一些功能有待完善。
但這些開發人員都很聰明，他們一直在按部就班地完成任務，我知道如果他們不累垮的話，我們一定能趕上測試日期。
所以，當 CTO 找到我並說接下來的假期取消都來加班時，我說「好吧」......
然後，在我一生中最自豪的時刻，想起我父親關於不管老板如何都要完成工作的建議……
我告訴我的三個夥計，「這周休息吧 我來搞定。」
每天早上我都會撥通 CTO 的電話，跟他匯報計畫進度情況，我撒謊說：
「團隊正在努力工作。今天我們達到了裏程碑式整合的第 73 步了」
「團隊昨天進展順利，我們又完成了一項網路服務」
每天，我都會出現在大老板面前，告訴他我們正在努力工作，而這些工作實際上我們已經在上個月完成了。
一周後，我的三個小夥伴精神煥發地回來了。
我們在一月份如期完成了任務，上線後取得了很好的效果，還當了一段時間的「搖滾明星」，感覺還是不錯的。
就在那一次，我對 CTO 撒了謊。
見解與看法？
面對 GrumpyOldDev 的經歷，不少人將原因歸咎為「公司不健康的工作氛圍」，也有很多開發者感同身受。
網友 knodi123：
這對你來說聽起來是不是很瘋狂？不過，在我的第二份工作中我就處理了完全一樣的事情。
整個客戶和產品資料庫儲存在一個面向公眾的 .js 平面檔中，該檔必須在應用程式執行任何操作之前完成載入（使用 2000 年代早期的互聯網）。而最糟糕的是，這個應用程式是一個單一的整體檔，位於一個名為 index.1.js、index.final.js、index.newest.js、index.45.js 等的目錄中。
我有足夠的最佳實踐經驗，可以去找我們的 CEO 並解雇 CTO，然後著手用 git、mysql 和帶有實際架構的伺服器端邏輯來重寫它。然後，它所執行的那個 Windows 伺服器被攻破變成了一個色情伺服器，盡管我從未見過該伺服器，甚至沒有管理員許可權，但不知何故，這是我的責任。
夥計，我最初的幾份工作真是受教育啊！
@karmajunkie：
我曾在一家公司（我就不提名字了）非常短暫地工作過，這家公司使用 ElasticSearch 來做這件事。每個客戶基本上都有一個用於數據輸入的客製表單，並且該表單上的每個欄位都成為 ES 中的一個欄位，即使系統中的所有其他表單上都有相同的欄位名稱和型別。最終，他們不得不與另一家公司簽訂合約，在客製集群上執行客製的 ES 構建，因為他們超出了 ES 中預設的 10k 欄位數量限制。
當很明顯他們對解決這個問題的興趣為零時，我提出了辭職，並很快找到了一份有合理架構原則的新工作。
網友 Flarg：
即使是最健康的大公司也會做這種事情，我曾在一些公司工作過，我也向幾家公司銷售過。不知何故需要一隊承包商來交付業務功能的低程式碼解決方案，延遲的計畫放棄關鍵整合以實作按時交付，但在功能上毫無用處，CTO 的下一份工作取決於給外包供應商提供工作。最糟糕的是，那些堅持說他們購買而不是構建的組織，但其軟體團隊卻比他們的外包供應商還龐大。
motbus3：
如果你是一個「交付驅動」的人，取消假期繼續工作，我會根據自己的經驗對你說：別再犯傻了。
我知道，特別是當你因努力工作而得到認可時，這很困難，但你每一分鐘都會後悔。
如果你在一家依靠你的假期和休假來銷售產品的公司工作，那麽你正在幫助創造一個有問題的世界。如果很多人都這樣做，那麽還需要做更多的事情。如果沒有人這樣做，並且表現得好像要求這樣做是荒謬的（事實確實如此），那麽沒有人會被迫這樣做，公司也被迫進行真實的估計，即使這會損害你最喜歡的 CEO 的口袋。
對此，你是否有過這樣的經歷？在開發中，又遇到哪些出乎意料的「坑」?歡迎留言，分享你的看法。
推薦閱讀：
