架構師多半是開發人員出身。開發人員的主要職責是解決程式設計問題。相比架構問題，程式設計問題的範圍更狹窄。很多程式設計問題是很小但比較棘手的演算法問題。這些問題在程式設計面試、書本及大學課程上經常以很抽象的形式進行描述，彷彿存在於虛空中，和現實世界毫無關聯。但複雜棘手的問題又是那麼誘人。久而久之，我們便不能自已地喜歡上來自這些問題的挑戰。我們不會過問這些問題是否有意義、是否有趣、是否有用或是否符合倫理道德。也沒有人會因為我們思考這些問題和更廣領域之間的關聯而付報酬。越是難以解決的難題，越會吸引我們一心想著去解決。我們沉醉於解決程式設計面試題，這些題目通常都事先不切實際地設定好一些約束。於是習慣了不去質疑約束。但是，這些難題只是為了引導我們去發現老師、面試官或導師己經知道的東西而設的一些教學工具而已。
架構師和開發人員因此學會了迅速進入問題解決模式（problem-solving mode）。但是有些時候，沒有解決方案才是最好的解決方案（the best solution is no solution）。有許多軟體問題根本就不需要解決。它們之所以看似問題，是因為我們只注它們的表面症狀（symptoms）。
來看記憶體託管（managed memory）的問題。在記憶體託管平台上開發的程式設計師。無須去解決記憶體問題，即使真有這樣的要求，他們中的不少人估計也無法解決。這些平台對記憶體管理的解決方案，可以部分描述為：不存在記憶體管理問題，所以也就無須開發人員去管理記憶體的問題。
再來看構建過程。複雜的構建過程要求使用大量相互關聯的指令碼，而且這些指令碼要遵循很多標準和規範。你可以運用自己高明的指令碼技能和最佳實踐去解決這個問題，這確實也非常過癮。這樣做，你無疑也會給同事們留下深刻印象。確實，沒有人能夠不解決這些問題也給人留下深刻印象。然而，如果能後退一步，看清我們正在解決的不是構建問題，而是自動化（automation）和可移植性（portability）的問題，或許我們就己經轉向使用一些現成工具，它們早就抽象了這些問題並很好的解決了。
由於架構師往往習慣於迅速進入問題解決模式，我們常常忘記，或者根本就不知道，該如何去審視（interrogate）問題本身。我們應該學會像長焦鏡頭一樣，不斷地拉近放遠，以確保正確的鎖定問題，而不是只一味地接受別人給出的問題。在需求面前，我們不應該成為被動的儲破罐，像糖果盒一樣時刻準備著掏出各色各樣的聰明點子。
不要立即著手去解決擺在面前的問題，而是看看自己能否可以改變問題。問問自己，如果沒有這個問題，系統架構會是怎樣的？這樣的自問自答，可能最終幫你找到更加優雅可行的解決方案。有時業務問題確時需要得到解決，但有時，或許並非那麼迫在眉睫。
我們必須戒除「問題解決迷戀症」。我們往往喜歡接手問題，彷彿自己是一名密探，在歐洲的某座橋上，手裡是剛收到的、藏著最新使命的自毀信封。在立即去尋找問題的答案之前，還是先想想，如果根本就不存在這個問題，這個世界又將會怎樣。
程式設計師，不要急於學習程式語言，先學會如何解決問題
這是一篇關於虛度青春的短篇回憶錄。多年來，我一直在學習程式語言，然後用它們來構建更好的投資工具。在建立 和風險管理模型之餘，程式設計方面的工作堆積如山。但實際上，我並沒有花太多時間在真正需要解決的問題上。我把大部分注意力放在了演算法和程式語言上。多年來，我每週都要花幾個小時學習計算機基礎知識，卻沒有...
程式設計師，不要急於學習程式語言，先學會如何解決問題
這是一篇關於虛度青春的短篇回憶錄。多年來，我一直在學習程式語言，然後用它們來構建更好的投資工具。在建立 和風險管理模型之餘，程式設計方面的工作堆積如山。但實際上，我並沒有花太多時間在真正需要解決的問題上。我把大部分注意力放在了演算法和程式語言上。多年來，我每週都要花幾個小時學習計算機基礎知識，卻沒有...
程式設計師，不要急於學習程式語言，先學會如何解決問題
這是一篇關於虛度青春的短篇回憶錄。多年來，我一直在學習程式語言，然後用它們來構建更好的投資工具。在建立 和風險管理模型之餘，程式設計方面的工作堆積如山。但實際上，我並沒有花太多時間在真正需要解決的問題上。我把大部分注意力放在了演算法和程式語言上。多年來，我每週都要花幾個小時學習計算機基礎知識，卻沒有...