中國人總是迷戀大而全的東西，這種清潔也深深影響了中國的程序員和軟件公司的老闆們。每一個項目或者產品在規劃之初和研發之中，都期望它能夠是一個功能非常強大和完善的東西。爲了這種期望，我們不得不把大道至簡的東西搞得非常複雜。偏偏，複雜是軟件的死神！
我們都是肉眼凡胎，根本無法看清複雜會給我們的程序帶來多麼可怕的毀滅。但這種毀滅會悄悄慢慢的出現，就像是用小火在煮你，讓你的研發能力和思考能力變得越來越糟，你很難察覺到，而當你察覺到時，那已經太晚了。在另一方面，你會很容易看到增加複雜度給你帶來的好處：增加一個新的擴展層，你可以實現新功能X；或把本來運行在一個機器上的進程分成兩個，用來解決當前系統的擴展瓶頸。但現在你的大腦裏必須想着這個新增加的層，或這還要實現一個遠程調用層來管理這兩臺機器。
基本上，程序員老手和新手一樣都很容易出現上面的情況。我認爲這些年我在這個行業裏學到的只是更擅長在兩者之前取得平衡；何時複雜一點是合理的，何時必須要拒絕。我經常回想起編程初期一位師長對某個程序所做的評論：它很快，因爲它沒有做多少事，代碼直接明瞭。
很多人都有這樣的經驗：我們可以絮絮叨叨地對別人數落半天，但要簡明扼要地指出對方的錯誤卻往往詞不達意。同樣的道理，我們似乎都很難把軟件寫得簡單明瞭。在編程語言的設計上你最容易看出這一點；新手設計出的語言總是包含大量的功能特徵，而很少像C語言那樣清爽明晰。如今的程序，動不動就牽涉多少個對象；這在分佈式系統裏就意味這你要移動多少的東西。
另外一個用來描述這個問題的詞是“才智”：引用另外一個C程序員的話，“調試糾錯程序比第一次編寫出這程序要困難兩倍，如果你是用盡了你所有的聰明才智寫出這程序，那根據這定義，你就沒有最夠的才智去調試debug它了。”
有些道理，只有在真實地遭遇經驗甚至教訓之後才能心悅誠服。有一個事很刺激我——太多的項目裏都有人認爲元數據編程很酷。我發現制定一個詳細的設計目標來評估新代碼是否有必要，這很有幫助。如果你可以說“這些代碼不能幫助項目的最初設計目標上解決任何問題”，你就能很容易的拒絕這些代碼。在Google，用來描述一個新項目的設計方案的文檔模板上，在其右上角有個區域專門列着目標外內容：對項目的合理擴展將會被拒絕。
計算機技術發展至今天，各種開發的工具或語言在虛擬世界裏爭奇鬥豔。但我們很容易發現，使用基礎的工具或語言能幫助我們抵制複雜。你很難寫出一個很複雜的C程序，因爲它裏面沒有太多的東西。C程序大多用大量的數組，因爲你只能用它，但結果卻證明，數組是非常好的東西——緊湊的內存使用，O(1)次的數據訪問，很好的數據存儲。但我從來沒有倡導過特意的使用一種老牌語言。我想嘗試的是：像C一樣編寫Python、Java以及其他新興語言。