對程式設計技術的熱情反而會使我們的工作更糟 · 哲學黑客
這是來自一篇生產實踐的經驗分享，程式設計師對技術熱情，而不是對業務理解的熱情會誤導企業軟體方向，導致很多挫折和失敗，技術不是越新越先進越好，而應該匹配業務領域：
“優秀的程式設計師對他們的工作充滿熱情”基本上是我們行業的常見現象。總的來說，這可能是真的，但最近我一直對“程式設計的熱情如何妨礙我們為公司工作得更好”而感到興趣，甚至可能導致我們在程式設計時更糟糕。
以下是我認為這種激情會讓我們的工作變得更糟的一些方法：
- 忽略了業務領域在構建優雅解決方案中的重要性。
- 關於技術債務風險的判斷不佳（因為啟發式影響）
- 堅持孤立主義，這可以使企業構建錯誤的東西。
- 生成器與市場質量不匹配，這會導致浪費精力。
- 過度專業化
這些都是我個人犯過的錯誤，雖然我認為程式設計的熱情和這些錯誤之間沒有必要的聯絡，但我認為我的激情在解釋我這個特殊情況下發生的一些錯誤中起到了因果作用。我認為這是違反直覺的，值得分享以防其他人發現自己處於類似情況。
讓我們詳細看看每個錯誤。
忽視領域
Eric Evans 以極好的觀察力開啟領域驅動設計：
軟體的核心是它能夠為其使用者解決與領域相關的問題......開發人員必須讓自己進入業務領域中以建立業務知識......然而，這些並不是現實中大多數軟體專案的優先考慮事項......
..大多數才華橫溢的開發人員對了解他們工作的具體業務領域並不感興趣，更不用說承諾擴充套件他們的領域建模技能了。技術人員更願意也更享受鍛鍊其有關技術技能(而非業務)的可量化問題。
如果Evans有關領域建模對於優秀軟體的重要性的觀點是正確的，那麼我們實際上更關注技術問題的傾向會讓我們分散我們建立優秀軟體所需的設計對話。
他在同一篇文章中對此有一個很好的比喻。領域無知的開發者就像一個攝影愛好者選擇了一個更好的鏡頭，因為總會有人走進那個鏡頭。
他說：電影製作人員專注於精確執行自己的專業。他擔心看過這部電影的其他電影編輯會根據其技術完美程度判斷他的作品。在這個過程中，場景的核心已經丟失。
影響技術債務風險的啟發式模糊判斷
我們作為程式設計師所做的很大一部分是管理技術債務。不幸的是，我們管理這種技術債務的大部分方式取決於我們對程式碼庫中技術債務的風險和影響的直觀判斷。這些直觀的判斷將貫穿於影響啟發式，這是我們潛意識用來通過考慮我們對X的情緒反應來判斷X風險的心理捷徑。
作為程式設計師，我們不喜歡程式碼廢話，因此我們可能會高估程式碼對業務造成的風險。受到廣泛尊重的程式設計師認為：通常還有其他更重要的因素會對企業造成風險。這是兩個例子：
良好的工程設計可能是專案成功的20％。糟糕的工程肯定會傷害專案，但只要其他80％的產品線正確，適度的工程設計就可以使專案取得成功......
-KentBeck，TDD示例
對於我們研究的絕大多數失敗專案，沒有一個技術問題可以用來作為解釋失敗的原因。我們的調查參與者最常引用的失敗原因是“政治”。
-Tom Demarco和Timothy Lister，Peopleware
程式設計師隔離主義
考慮兩個關於程式設計師如何參與非程式設計活動的觀點：
1. 在Joel Spolsky的觀點中，開發人員應該通過“開發人員抽象層”與業務隔離。事實上，他說，“管理層的主要責任是建立l幻覺：軟體公司可以通過編寫程式碼來執行，因為編寫程式碼是程式設計師所做的工作“。
2. Marty Cagan有一個非常不同的看法。他說，“如果你的程式設計師只是程式設計，你只能獲得一半的價值。”支援驅動的開發還需要軟體開發人員實際上提供客戶支援 ，甚至成為像Zapier1 和Wufoo 2 這樣的公司。
簡單地追問哪個觀點更正確本身是一個糟糕的問題。更好的追問是：
- 在哪種情況下每種觀點更合適？
- 我們通常會針對正確的情況選擇正確的觀點嗎？
我認為我們經常搞砸了，我認為程式設計師的激情與這個錯誤有關。我認為我們往往傾向於支援Spolskian觀點（第一個觀點）。但是當一個專案的“如何做”比“做什麼”更模糊，我們才應該更傾向於Spolskian的觀點；當“做什麼”比“如何做”更為模糊時更傾向於Caganesque的觀點。
如果您確切地知道您需要構建什麼，但是您關心的是如何構建它，那麼將開發人員與業務隔離開來就是一個很好的選擇。
如果你不知道你需要構建什麼以及如何做是相當簡單的，那麼應該招募開發人員來幫助企業瞭解要構建的內容。這意味著程式設計師可以提供構建內容的可能性空間的精彩地圖。
問題在於，我們對技術問題的熱愛可以使企業為錯誤的環境選擇錯誤的觀點。
如果企業想要隔離我們，以便我們可以愉快程式設計，真棒。你不會得到我們的任何爭論。我們將忙於程式設計。
由於作為程式設計師自身成長通常是依賴一大群使用者實際使用產品之後才會發生，允許業務這些錯誤發生對於我們作為程式設計師的成長和對業務造成的不利影響實際上是不利的。
開發產品高於市場質量標準
讓我們從坦白開始：我經常讓自己“修復fix”我不願再多看一眼的某部分程式碼庫。即使這不會導致意外的錯誤，通常也需要一段時間才能交付。“只是解決技術債務，”我說。
有些人卻能坦然處之，我曾在雅虎見過一位工程師說在開發衝刺計劃期間可以呼叫“開發者幸福”來證明在某些事情上的合理性。Peopleware的作者實際上聲稱軟體質量應該由程式設計師而不是市場來設定。他們說：
“我們都傾向於將自尊與我們生產的產品的質量緊密聯絡在一起...... 只要你忽視對開發商的態度和效果的影響，市場衍生的質量標準似乎才有意義......”
這是一個強烈的主張，我懷疑是完全正確的，但在某種程度上，這是真的，這意味著公司浪費資金滿足我們的質量慾望，因為我們的質量標準超出了市場對質量的要求。
這在啟動時尤其成問題。早期創業是一場生存的戰爭，所以當我們對程式設計的熱情驅使我們堅持比我們客戶的要求更高的質量時，我們最終表現得就像那些被困在戰壕中的士兵一樣拋光我們的步槍因為它讓我們感覺更好。(banq注：對技術熱情會提供高質量的產品，但是市場不需要這麼高質量，而高質量需要成本和時間，創業企業會錯失良機，敏捷更重要，使用Ruby/PHP開發一個網站可能會比用Java更有效，雖然沒有細粒度的分層架構)
我並不是說關心軟體質量不是好事情，我只是認為在創業公司，如果程式設計師專注於這些事情而不是生存，那就太難生存了。
過度專業化
有一段時間了，我懷疑程式設計師的專業化對於企業來說反而應該是次優的。Andy Grove的用餐比喻和他在High Output Management中的“限制步驟”的概念給了我一個很好的方式來解釋為什麼這可能是真的。
Grove說：如果我們想要熟練地運營一家餐館（或招募人才，或者建立一個編譯器），我們最好確定建立早餐所需過程中的“限制步驟”：在含有雞蛋，烤麵包和咖啡的早餐中，準備雞蛋是限制步驟。
這是因為準備雞蛋需要花費所有步驟的大部分時間。無論我們準備咖啡和烤麵包的速度有多快，我們所供應的早餐數量最終將受到雞蛋準備時間的限制，這反過來限制了用餐者可以產生的收入。在許多技術公司中，有一種類似於雞蛋製備的技能，因為它限制了可以開發功能的總體速率，這反過來限制了公司可以從這些功能中產生的收入。
上述餐廳的一名員工認為提高她的咖啡準備技能實際上會幫助企業弄錯。這同樣適用於那些認為專注於非限制性規則對業務有利的程式設計師。程式設計師對他“最喜歡的技術堆疊”的熱情可以使她失明。
在很多情況下，即使程式設計師專注於非限制性規則/堆疊，持續專業化實際上也會為業務帶來好處。專家可能能夠在更短的時間內生成更高質量的程式碼，從而減少錯誤，這可能會導致軟體產品的推薦人數增加。此外，更深入的知識可以更加豐富地瞭解指定技術堆疊的可能性，從而更好地為產品和專案管理決策提供資訊。
然而，在某些時候，對質量的進一步投資和跟上解決問題的所有最新方法將會產生收益遞減，我懷疑這一點比我們很多人意識到的要早得多。
(banq注：這是來自一篇生產實踐的經驗分享，程式設計師對技術熱情，而不是對業務理解的熱情會誤導企業軟體方向，導致很多挫折和失敗，技術不是越新越先進越好，而應該匹配業務領域，領域驅動設計=業務領域驅動設計=業務驅動設計，而我們平時是技術驅動設計或者資料驅動設計，後兩者都過於偏重技術！)