+10 倍工程師可能是神話，但 - 10 倍工程師確實存在。
要成為 - 10 倍工程師，只需每週浪費 400 小時的工程時間。結合以下策略：
-
使 10 名工程師的產出無效。
在開發過程中盡可能改變需求。為了避免責任，從一開始就模糊需求。 -
創造 400 小時的忙碌工作。
要求你的團隊執行類似工作的任務。常見的例子包括演示、圖表和票務管理。創造無意義的儀式。 -
創造 400 小時的倦怠 / 流失。
不知感恩。推卸責任。播下混亂的種子。生氣。讓其他人加班。 -
在技術討論中挾持 10 名工程師。
讓工程師討論想法。鼓勵他們追求優雅而非務實。確保沒有人有權做出任何決定。 -
增加 400 小時的溝通開銷。
會議破壞日程。為了不引人注意地浪費他人的時間，撰寫冗長的消息 / 文件並盡可能廣泛分享。歡迎所有意見並旨在促進參與。 -
在雲端成本上浪費 10 週的工資。
編寫慢速程序。避免數據庫索引。在 16 核機器上運行單線程程序。選擇具有華麗 RAM 和 GPU 的異國硬件。隨意在 RAM / 磁碟上存儲數據。不壓縮任何東西。對數據佈局不予關注。 -
創造無用的工具。
決定現有解決方案不完全符合需求。編寫只有一個人能理解的腳本。如果腳本執行重要操作，避免文檔。 -
增加 400 小時的編譯 / 構建時間。
慢速構建浪費時間並產生複利。隨著構建時間的增加，開發人員更容易分心。為了確保開發人員在上下文切換，重新編譯應至少需要 20 秒。你也可以編寫慢速測試以達到類似效果。 -
編寫無意義的測試。
創建對特定變量的依賴，而不測試底層功能。模擬函數調用，直到沒有原始代碼運行。將微妙的隨機性引入測試中，使其無故成功 / 失敗。 -
在糟糕的架構上浪費 400 小時的工程。
對系統設計如何隨時間演變毫無考慮。或者，驅使你的團隊過度關注架構決策，以至於沒有時間測試他們的假設。 -
在部署上浪費 400 小時。
創建盡可能多的環境。生產和預備環境必須大相徑庭。啟動脆弱的代碼和脆弱的構建系統。頻繁遷移數據庫。 -
在不滿意的客戶上損失 10 週的工資。
反覆未能檢測和解決嚴重錯誤。對安全漏洞不予關注。 -
編寫毫無價值的文檔。
在私人消息中解釋代碼。編寫沒有人使用的維基。 -
讓 10 名工程師陷入無用的秘密項目。
吸引優秀工程師並浪費他們的潛力。對管理層低估項目的難度；高估項目的實用性。告訴管理層它 “幾乎完成” 直到他們放棄它。 -
增加需要 400 小時維護的依賴。
工程師各自學習每個庫。 -
延遲轉型。
永遠不承認失敗。讓你的團隊陷入沉沒成本。忽視可以改善你情況的 80/20 妥協。 -
雇用 10 名 0x 工程師。
機會成本可能致命。死重可能不會積極傷害你的團隊，但他們佔據了可以積極幫助的人的位置。 -
雇用 5 名 - 1x 工程師。
不要滿足於死重。積極雇用會造成災難並抵制學習的工程師。 -
阻止 10 名 - 1x 工程師被解雇。
不要搖動船隻。不要留下失敗的書面記錄。為糟糕的工程背書。 -
產生 400 小時的錯誤分類。
製作無法調試的程序。在所有事物上覆蓋抽象層。編寫意大利面代碼。讓一切對初始條件敏感。避免純函數。隨意使用依賴。每當可能時說 “它在我的機器上運行”。