我從開始職業生涯之前，甚至還在讀中學的時候，就一直熱衷於撰寫「優良程式碼™」。
優良程式碼是容易閱讀和理解的程式碼。優良程式碼是開發和維護起來令人愉悅的程式碼。優良程式碼是為了特定目的而存在，且僅此而已的程式碼。優良程式碼是才華、經驗、熱情以及可能對公司業務沒有立即效益的時間投入等稀有組合的產物。而最不幸的是，優良程式碼非常罕見。
話雖如此，我的職業是一名軟體工程師。不是「電腦程式設計師」，也不是「程式設計師」，或任何暗示我的工作是「撰寫優良程式碼」的頭銜。事實上，我的職稱沒有任何一項要求我必須閱讀或編寫程式碼！我的工作是創造有用的軟體來解決實際問題。
最近，我在 Modal 的一位同事重寫了一個與 Linux 核心深度整合的外部系統。最初的重寫只是將 C 程式碼庫翻譯成 Rust，為一些客製化功能做準備。產生的程式碼不算差，也不是不符合慣用 Rust 風格的程式碼。但它也不是優良程式碼。它難以閱讀和理解，將來會難以擴展和維護，而且我們甚至不清楚為什麼我們要承擔重寫和維護這個額外系統的負擔。
最初的重寫也嚴重依賴了程式碼生成代理。
接著，這位同事投入時間去理解核心子系統，理解原始 C 程式為何以那樣的方式編寫的確切原因，然後自己重寫了 Rust 的翻譯版本。差異是天壤之別；程式碼自然流暢，解釋了它本身以及底層子系統，而且可能確實是整個程式碼庫中最優雅的部分。我認為，即使這種類型的程式碼是使用 C 而非 Rust 的最佳場合之一，它也比原始的 C 程式碼更好。
這是幾週，甚至幾個月來，我第一次感受到過去在日常工作中很常見的一種感覺：對眼前的程式碼感到興奮。我過去幾乎每天都撰寫（近似的）優良程式碼。不知何故，一切都改變了。現在，我甚至不寫我提交的大部分程式碼的第一個版本。有了代理在身邊，我的生產力無疑大大提高。它們在編寫程式碼方面並非完全糟糕，只是不夠出色。歸根結底，它們產出的程式碼是……可接受的。它能完成工作，通過我的嚴格測試，但絕對不是優良程式碼。
也許關心這些程式碼的時代已經過去了。我確信曾有人對優良的組合語言或優良的電路充滿熱情，但隨著時間的推移和領域的演進，他們的熱情已悄然消退，成為「過去的樣子」的回聲。從我（有偏見的）角度來看，軟體工程的變化感覺異常突然，我忍不住哀悼優良程式碼的無聲死亡。