人類打造工具、工具反過來增強人類，這種往復的循環讓人振奮，也讓我深受感動。

(計算機史，來源 Alan Kay - ARPA / Xerox PARC culture)

介紹

這本書是 Richard Hamming 在 1995 年在美國海軍研究生院所給的課程所彙總成的一本書。它的核心出發點在「一個沒有努力使自己卓越的奮鬥人生，幾乎不值得過」，核心主張是「Luck favors the prepared mind」，核心內容則是作者透過對自身卓越科研事業的內省，以及對貝爾實驗室著名的同事 (Claude Shannon, John Tukey 等) 的觀察，回答如何成為 prepared mind (style of thinking)。

作者的另一個核心目的是希望啟發你去尋找自己的思維風格，設立一個使命和前進的方向。你必須要思考，必須要成就一些超越自己的、有意義的事情。舉例而言，一個醉酒的水手隨機遊走最終的走的平均距離是 \sqrt n，而如果一個漂亮的女孩站在某個方向，那麼水手最終走的平均距離會和 n 成正比。Hamming 另外觀察到，最開始的 vision 是否正確無關緊要，指向卓越的道路很多條，任意一條都比隨波逐流更好。

換句話說，這本書在嘗試 prepare you for your future。作者在 1995 年講課的時候，他已經觀察到人類的科技進展速度在加速、知識迭代的速度越來越快，十五年前學的技術知識到現在可能已經一半都已經過時了。但未來仍有無限多的機會等著你去發現，因此他向你展示他是如何從第一行原理關注和預測當時的顯學 (Fiber Optics)、如何透過對二進制數學的深入理解發明改變世界的科技 (Error-correcting-code)、如何在不完全理解的情況下進行有效研究 (quantum mechanics)、如何用系統工程的角度去做事、如何利用計算模擬中發現設計啟示 (NIKE missile)等等。應對科技快速變遷的唯一方法是學會學習 (learning to learn)，也就是本書的副標題。

這本書原本的主要讀者是當時美國海軍工程學院的學生，但我個人覺得它的受眾包含所有有志在科技社會中做巨大貢獻的人，特別是科學家與工程師（本科學生和碩博生）。原因有兩個，第一你需要感受到一名教授對你追求卓越的鼓勵，其二，你需要被引導、被有系統地曝光於上文所展示的那些思維與方法。

本書旨在帶領讀者探索多個不同且高度技術性的現代研究領域，從中萃取出作者特別強調的一套思考風格。因此，書中包含許多較為硬核的內容，諸如 information theory、coding theory 以及 digital filter 等相關主題。

在選擇方向的時候，你勢必需要回答下面三個問題：

1. 有什麼是可能的？（科學問題）
2. 什麼是很可能發生的？（工程問題）
3. 什麼是我們希望發生的？（道德問題）

這些與未來相關的問題很難回答，人類僅有的參考是歷史，結合計算機正在快速改變人類的所有領域，因此計算機歷史是貫穿本書的基調。

在本書講述的所有主題中，教育 (education) 與訓練 (training) 的區別是貫穿所有章節和主題的脈絡，也是區分領導者與跟隨者的關鍵。在未來進入領域工作後，你不是領導者就是跟隨者，作者希望你成為領導者。

閱讀建議

推薦先以讀 blog 的心態讀一下 You and Your Research (30 min read)，感受 Hamming 對長江後浪的滿腔期許。如果你對這本書感興趣的話，我推薦你把它分為不同的區塊，然後每個區塊當做一個 blog 或 blog series 去閱讀。比如說 History of Computers 是一個 series，AI 是一個 series，Coding Theory and Information Theory 是一個 series，然後 Simulation 是一個 series。其他的更像是一個單篇的 blog，比如 System engineering。書中每個 “series” 或 “blog” 都會有一些 meta point，閱讀的時候重點放在弄懂他的 meta point，而不要專注在繁瑣的 technical detail 和故事。

以下我分享我覺得有用或有趣的部分筆記，完整版請參考此白板。

教育 (education) 與訓練 (training)

Education is what, when, and why to do things. Training is how to do it.

兩者之間的差異，用系統工程的角度來看，訓練是教會學生如何解決一個被清楚定義的問題，像是什麼情況用什麼技巧，如何使用技巧等。而教育則是讓學生面對一個模糊的問題時，有能力判斷如何運用不同課程的知識去不斷重複界定問題，進而選擇合適的技巧來解決它。

對科技社會的領導者而言，what, when 和 why to do things 遠比 how 更重要（當然 how 也非常重要）。Hamming 的提醒是：「從別人那裡學到的，你只能用來跟隨；你為自己學到的，才能用來領導。」教育的真正目的，在於培養願景、判斷力與自我修正的能力，使人能在未知中選擇方向、調整路徑。面對知識半衰期快速縮短的世界，教育更專注於「為未來準備」而不是拘泥於「如何」的細節。

從健身的角度來說，舉 40 公斤兩次帶來的肌肉成長，通常比舉 20 公斤四次要顯著。這種對「物理肌肉」的鍛鍊方式，是否也適用於「心理肌肉」？兩者或許不完全等效，但這個類比在何種程度上是合理的？至少在某種意義上，深度的思考挑戰比淺層的重複練習更能鍛鍊心智。

從知識攝取層面與日常思考方面，作者建議：

• 建立深厚的基礎：技術的細枝末節迭代的速度特別快，但基本觀念卻往往能夠跨時代遷移。
• 不斷學習新知：知識指數增長，你需要主動跟上那些新興領域。
• 能夠快速建模：做 back-of-the-envelope calculation，擁有快速數學建模去估算與驗證他人主張的能力。
• 定期思考宏大的問題：Hamming 建議每週花一下午，也就是 10% 的工作時間，去思考那些具有前瞻性、開放性的問題。比方說「計算的本質是什麼？它將如何影響科學的發展？電腦在貝爾電話實驗室的自然角色是什麼？電腦將對 AT&T 產生什麼影響？對科學整體又會有什麼影響？」他提到這樣他就會知道人類將要前往的方向，從而能朝著正確的方向前進。且不會像那個「東倒西歪、許多步驟又被隨機其它步驟抵消」的醉酒水手，而能夠較為直線地前進。也能密切關注重要問題，確保他的主要精力投放在它們上面。

Error correcting code 的發明

Error correcting code 的發明徹底改變了通訊與儲存系統，使得他們能在有噪音的情況下以極低的冗餘率自動檢測並修正錯誤，是現代技術的基石。

Hamming 之所以能發現 error correcting code，是因為他當時飽受機器出錯的折磨。當時的機器在運算時時常會因為 code 中出現錯誤而無法按預期完成計算，比如 0 突然變成 1，或 1 變成 0。好幾次因為這個導致計畫落後之後，他非常生氣，並提出一個問題：「既然這些機器能夠偵測到錯誤，為何不能定位錯誤的位置並主動修復它？」

他知道能用存儲多次的方法，用多數決去實現自動 error correcting，但這個方法的冗餘率太高，在記憶十分寶貴的時代行不通。他知道一定有更好的做法可以達到自動糾錯，因此他著手研究這個問題。他對 two‑out‑of‑five code、parity checks 以及二進制的理解，加上作為數學家的紮實數學基礎，對他發展 error‑correcting code 幫助很大。在當時，多數科學家、計算機科學家與從業者並不熟悉二進制數字與二進制演算法。那個年代，人們還傾向使用熟悉的十進制，而不像今天普遍認為二進制對計算機更為合適。

Hamming 發明 error‑correcting code 的關鍵在於一個極簡而深刻的洞見：將檢測到的錯誤「症狀」本身視為一個二進制數字，而這個數字直接指出了錯誤發生的位置。在此基礎上，他進一步提出，若要直觀地探索二進制碼的能力與極限，應該將度量碼距的空間從傳統的歐幾里得空間 Euclidean space 轉換到二進制度量的的 Hamming space，從而建立了一套全新的幾何框架來設計與分析錯誤更正碼。

真正的創意來自於被問題飽和的潛意識

「Originality」的意思不僅僅是沒有被做過，你可以做一些微不足道的事，比如把兩個隨機的十位數相乘，但這樣做不會有任何有意義後果。創造力似乎是「有用地」把先前未被認為相關的事物組合起來，而可能最重要的是事物之間最初的心理距離 (psychology distance)，如同前面 error-correcting code 中，計算兩個位串之間的距離時使用 Hamming 度量而不是 Euclidean 度量。

人們可以更具有創造力嗎？市面上大多數創造力課程和工具似乎並不是特別有幫助，因為它們從未在任何領域產生大量主導人物。在整本書中，創造力被稱為「風格」，Hamming 相信人們可以更具有創造力。一個創造性行為通常從以某種模糊的意識識別問題開始，隨後對問題進行收斂。在收斂的時候，不要太快給它下框架，因為你會把它放入一個常規的形式並得到常規的結論。在這一階段，需要深刻的情感投入以真正投入其中。對問題的長時間醞釀可能導致暫時的解決方案或暫時放棄問題。這是許多偉大創造性行為的共同過程，但這對讓潛意識去思考這個問題而言是必不可少的。

接下來迎來的就是洞見或「創造力」的時刻。錯誤的起步和錯誤的解決方案常常會使你下一次嘗試的方法更為銳利。你現在知道哪些做法是錯誤的了！你剩下要探索的方向更少了。你對什麼行不通以及可能為何行不通有了更好的理解。

如果解決方案來自潛意識，那麼我們可以用這個問題來飽和潛意識 (saturate the subconscious with the problem)。如果我們幾小時、幾天、甚至幾週都不去想其他任何事，那麼我們甚至還會在睡眠中咀嚼這個問題！ Luck favors the prepared mind, and you can be prepared.

在創造的過程中，類比推理 (reason by analogy) 是最重要的工具之一。廣泛涉獵不同領域的知識會對此大有裨益，前提是這些知識能被靈活地取用。這有賴於你在學習新知時，不斷地從多元角度審視它，為它建立許多「知識掛鉤 (knowledge hooks)」。如此一來，當你需要時，才能透過類比從心智中鉤出那個關鍵的想法。

如果你不著手於重要的問題，你怎能期望做出重要的工作？

這一節的內容取自 You and Your Research

「我覺得做有意義的事比僅僅混日子直到生命終結要好得多。當然，在生命將盡時，回首一生中的成就總比回顧一個只是活著並自娛自樂的生活要令人欣慰。這意味著兩件事，(1) 值得為自己設定崇高的目標，(2) 值得去努力完成你為自己設定的目標。」

因此，你必須大膽地向自己承認：「我想做出一流的工作！」畢竟，如果你不致力於解決重要的問題，又如何能期望做出一番重要的事業呢？

許多人會用「我不夠聰明」作為藉口，但許多看似沒有極高智商的人也做出了偉大的事。例如，在貝爾實驗室中，Bill Pfann 起初看起來並不特別聰明，但他在區熔（zone melting）方面的工作贏得了這一領域所有的獎項，並且隨著信心的增長，他也變得更能言善辯。能力有很多種形式，不僅僅是智商。

比起高智商，信心或許是更關鍵的特質，你也可以稱之為「勇氣」。這種勇氣可以後天培養，多專注於你的成功，少關心你的失敗。如 Claude Shannon 在下棋時，常會大膽地將皇后推入戰局，說：「我什麼都不怕 (I ain’t scared of nothing)。」當你陷入困境時，不妨也這樣告訴自己。

擁有雄心和勇氣後，下一步是確保你把精力花在「對」的問題上。為此，你應該定期挪出時間，思考那些更宏大的「偉大想法」：你所在領域的本質是什麼？它將如何影響科學的發展？如果你想成為引領者而非跟隨者，就必須跳脫出多數人深陷的細節之海，時常審視大局。一個具體的方法是，在心中常備一份清單，列出約 10 到 20 個你關心但尚不知如何解決的重要問題。偉大的科學家們總是如此，他們將這些問題放在心上，一旦出現線索，便會立刻投入其中。

對卓越的渴望是做出偉大工作的基本特徵。沒有這樣的目標，你會像一個醉酒的水手一樣四處遊蕩（平均到 \sqrt{n}）。

如何關注一個新興領域，並為此做準備

我們該如何面對一個潛力巨大的新興領域？Hamming 以他親身經歷的光纖 (Fiber Optics) 技術崛起為例，說明了他應對一個全新領域時所採用的思考模式。

首先，漢明從「第一原理」出發，迅速辨識出光纖的重要性。物理學原理揭示了光學頻率遠高於當時使用的電器頻率，因此能提供更大的頻寬；而其原料是取之不盡的沙子，對比日益稀缺的銅礦，成本優勢顯而易見。此外，他注意到當時紐約曼哈頓的電話線管道空間已趨飽和，若城市要繼續發展，直徑更小的光纖是唯一不必重新大規模開挖街道的解決方案。這些原因讓他確信，他所在的貝爾實驗室勢必會全力投入這項技術。

接著，他持續追蹤自己預見的技術瓶頸，並隨著領域演進更新知識。例如，他很早就意識到「如何拼接髮絲般細的光纖」會是實務上的一大難題。他也觀察到當時的系統需要將光學信號轉為電子信號來放大，再轉回光學信號，他認為這是個糟糕的設計，並預見了「光學放大器」的必然出現。此外，他還意識到光纖不受電磁干擾（例如核爆或雷擊）的特性，這意味著它必然會獲得軍方的大力支持。透過關注這些關鍵問題，整個領域的發展藍圖在他眼中變得清晰可見。

你應該永遠主動提出問題，才能更好地預測並引領未來，而不是被動地跟隨趨勢。

計算機時代的教育與訓練

在計算機發展的時候，有大量的教育研究指出，計算機對教育有益，並且能夠輔助訓練學生。然而多數的教育實驗並沒有解決掉 “Hawthorne effect”——即人們因為感受到自己正在接受特殊關注或觀察而帶來的短暫表現改善。新學習方法所表現出的大多數效益增長通常反映了這種偏見，而非實質的改善。

高等教育的標準一直在變。未來的教育將與現在的教育大相徑庭，就像現在的教育與十九世紀的學習幾乎毫不相干一樣。教育系統會隨著技術的飛躍而劇烈躍進。若沒有對未來何種教育形式適切的願景，我們又如何評估擬議的 CAI 專案？我們必須建立一個對未來社會受過教育者樣貌的願景，只有如此，我們才能有把握地處理 CAI (computer aided instruction) 中出現的問題。

Hamming 認為計算機有助於低階、條件反射式訓練，但在教育方面則不那麼有用，部分原因如上所說，是我們還不知道在新時代中「受過教育的人」意味著什麼。(2025 年， Eureka Labs 的 Andrej Karpathy 有話說）

我們所教/所學在多大程度上是訓練，而在多大程度上是教育？

系統工程

系統工程的核心理念是時刻關注宏觀目標，並將局部行動轉化為整體的成果。

系統工程視角 (system view) 與執行者視角 (task view) 的根本在於「我在建造大教堂」和「我在雕刻一塊石頭」。許多人自以為以為理解了這點，但大多數時候都還是沉浸於細節之中，而沒有思考更大的圖景。因此，衡量一個系統工程師應當以他們產出的東西為主，而不是他們所說的話。

系統工程的第一條規則是：「如果你優化小的組件，你很可能會毀掉系統的性能。」如果你專注於一個簡單組件的優化而不注意它對整體目標的影響，那麼你就會毀掉整體目標。工程上有這樣的例子，但一個更容易理解的例子是教育：如果你在學校不斷找捷徑（比如面向往年題複習），那你所受到的學校教育就是失敗的。

對教育採取系統工程的做法是讓學生通過基於主修的九門課的綜合考試。在這種情況下，當修任何一門課時，重點就不是為了通過這門課、討好教授，而是要學會課程內容，這樣在以後（2年後）的某個時間你仍會記得課程中重要的知識。畢竟，教育重要的是最終呈現出的成果，而每個階段發生的事情則不像最終結果那麼重要 (what matters in your education is what emerged at the end, and what happens at each stage is not as important)。

系統工程的第二條規則是：設計必須具備靈活性，為變化做好準備，確保在調整時能平穩過渡，而不損害其他部分的功能。技術知識的半衰期大約只有 15 年，對教育而言，這意味著今日所學的許多細節在未來可能不再適用。因此，教育的目標應是為你的未來做準備，更著重於傳授基礎原理，而非那些稍縱即逝的枝微末節。

系統工程的第三條規則是：設計應能在超載時實現「優雅降級 (gracefully degrade) 」。一個設計如果過於貼近其規格，當負載超出預期時，其失效將會非常迅速且徹底，就像是為特定載重設計的橋樑或為最大流量設計的電話系統。一個好的系統，則會在壓力超出極限時，性能逐步下降，而非直接崩潰。

系統工程是一項永無止境的任務。首先，任何解決方案的出現都會改變其所處的環境，從而引發新的問題。其次，解決問題的過程往往會讓工程師對問題本身產生更深刻的洞察，進而不滿足於現有的方案。在系統工程中，並不存在所謂的「最終解答」，因為每一個解決方案都應為下一輪的改進提供新的見解。一個無法帶來新洞見的方案，幾乎不能稱之為解決方案。因此，系統工程的核心是接受一個事實：問題和解決方案都不是固定不變的，演化才是常態。

學校教育通常提供的是有明確定義的問題和唯一的正確答案，但現實世界的系統工程工作恰恰相反，它始於混亂、模糊的背景，需要工程師從中塑造出一個可行的方案。Hamming 認為，學習系統工程最好的方式，是將課堂上學到的理想化解法與複雜的現實情況進行對比。系統工程的目標是正確地解決「對的問題」，即便解決方案本身可能不完美。每個方案都只是暫時的，但它所帶來的深刻理解，將為下一輪的設計迭代鋪平道路。

所測及所得 You get what you measure

這裡的「測量」，不僅指具體的數據，更泛指所有與設定指標相關的體系，例如教育目標、招聘標準、績效評估方法及晉升機制等。 這個概念提醒我們，測量工具本身會深刻影響我們所觀察到的結果，如同漁夫用特定網孔的漁網捕魚，最終會誤以為海裡的魚都有最小尺寸限制。 在設計任何衡量指標時，都必須深思熟慮其可能帶來的深遠影響。

舉例而言，評等系統會影響冒險行為：

• 想像一個評分系統，每個人的初始分數都是 95%。在這種機制下，個人幾乎沒有提升空間，任何失誤卻都可能導致分數下降，於是，最理性的策略便是規避風險、採取保守作風。 雖然組織高層可能希望提拔具有冒險精神的領導者，但最終能晉升到高位的，卻往往是那些最懂得規避風險的保守派。
• 相對地，如果初始平均分數設定在 50%，則會鼓勵較為平衡的行為。若想進一步激勵創新與冒險，可以將初始分數設在 20% 或更低。在這種情況下，員工因失敗而損失的有限，成功的收益卻很高，這自然會鼓勵他們勇於嘗試。 因此，若想在組織高層看到真正的冒險家，就必須在早期階段的評量與晉升機制中，為承擔風險的行為提供正向激勵。

你用於錄取、聘用或晉升的短期指標，長期來看可能也可能並非你真正想要的。你用來選人的指標，之後可能會適得其反。在數學與電腦科學領域，最初的選拔是基於可靠執行某些心智任務（如解題）的能力，但之後你需要的是能夠從整體上看待該領域（看到更大的圖景）以及能夠猜測出重要新結果的能力。同樣地，在招募時，對典型招聘者有吸引力的特質，可能並不是合適的人選。因此貝爾實驗室的研究人員親自進行招聘。

測量的準確性 (accuracy) 也常常與測量的相關性 (relevance) 混淆，例如：衡量「訓練」很容易，而衡量「教育」卻很困難。另一個經典例子是智商測驗。這類測驗的設計和校準，本身就是為了使其分數分佈符合常態曲線。因此，「智力呈常態分佈」這個結論，與其說是反映了智力的真實樣貌，不如說是測量方法本身所導致的人為結果。

在任何組織中，你需要意識到一個事實：人們會圍繞你設定的指標進行優化，而不是你設定指標時的初衷。 各層級的員工都會想方設法讓自己的數據看起來更亮眼。 更糟的是，指標的意義在不同層級之間傳遞時還會失真。例如，基層單位對「組織能力」的評估報告，到了高層眼中，可能就被錯誤地解讀為成功的「機率」。

當指標改變，行為也會隨之調整。軍隊的正式檢查，教會了各單位如何「表演」戰備狀態；定期檢查會被刻意準備，就連所謂的「隨機」抽查也常被提前預知。 商業或戰爭遊戲的訓練，也往往是讓領導者學會如何贏得模擬競賽，而非現實世界的挑戰。 因此，在設計任何測量系統時，你不能只考慮其一階效應，更要預測並應對它將引發的二階、甚至更高階的行為反應。

高維空間對複雜系統設計的啟發

當我們設計一個複雜系統時，若將所有可用的參數都考慮進來，就相當於在一個 n 維空間中尋找最優解。但當維度 n 變得非常大時，這個設計空間的主體究竟在哪裡？是在這個 n 維球體的「表面」，還是在其「內部」？這個問題的答案，對我們如何尋找最佳設計具有一定的啟發。

為了解答這個問題，我們可以比較 n 維球體最外層的薄殼 (shell) 體積，與整個球體體積的比例。假設球體半徑為 r，而我們考慮一個內層半徑為 r(1-\epsilon) 的球體，那麼最外層薄殼的體積佔總體積的比例為：

這表示，球體的體積幾乎完全集中在靠近表面的薄殼上。舉例來說，如果我們考慮外層一半的半徑範圍（即 \epsilon = 1/2），在三維空間（n=3）中，這層薄殼就佔了總體積的 1 - (1/2)^3 = 7/8。隨著維度 n 增加，這個比例 1 - (1/2)^n 會迅速趨近於 1。

換句話說，最佳設計幾乎肯定位於可行域的「表面」，而不是「內部」。這可能與我們在基礎微積分課程中學到的優化方法相悖，因為那些方法通常在內部尋找極值點。但在高維空間中，最佳解往往是將一個或多個設計參數推到其允許的極限值，這自然就意味著我們處在設計空間的邊界上。

FORTRAN 戰勝時間

在計算機中，指令的意義來自於其執行過程，符號本身不具有內在含義。這就是所謂的「語義來自實現」（Semantics comes from implementation）。換句話說，是那些被編寫出來用於執行特定操作的子程序 (sub-routine)，定義了一門程式語言的真正意義。

在非常早期的計算機時代，程序的控制極度依賴人工。從桌上計算器到由接線板 (plug board) 控制的打孔卡機 punch card，再到紙帶和 ENIAC 最初透過複雜佈線 (wiring) 來控制，無一不是如此。

為了簡化程序設計，一群科學家發明了抽象符號 symbolic abstraction，比如說讓 ADD 這三個字在編譯的時候自動變成如 1011 的二進制的機器碼。有趣的是這種符號組合語言 (Symbolic Assembly Program, SAP) 的出現被當時的硬派程式設計師視為異端、「娘炮玩意兒」(sissy stuff)，而不屑使用。

在 SAP 的基礎上，John Backus 和他的團隊在 1950 年代提出了 FORTRAN（意為公式翻譯 Formula Translation）。Hamming 的經驗是，他的程式設計師使用 FORTRAN 後，產出效率提升了近十倍。然而，當時的專業程式設計師社群普遍抵制它，主要理由有三：首先，他們認為這不可能實現；其次，即使做得到，也會極度浪費寶貴的機器時間和儲存容量；最後，就算它真的能用，一個有尊嚴的程式設計師也不屑於使用。

FORTRAN 最終普及並經受住了時間的考驗，而許多後來者，如 Algol，卻失敗了。根本原因在於 FORTRAN 的設計更符合人類的心理直覺—它將人們在學校早已習慣的數學公式直接翻譯成程式，不需要學習全新的思維方式。相比之下，由邏輯學家設計的 Algol 雖然在邏輯上更為嚴謹優雅，卻因不夠人性化而最終被淘汰。這表明，符合人類心理的設計，其生命力遠超純粹邏輯的設計。

這段歷史提供了一個啟示：一項工具能否對人類產生深遠影響，並經受時間的考驗，關鍵在於它是否足夠貼近人性。

人機溝通的問題 (Human Computer Communication)

大多數現代軟體的核心問題仍舊是「什麼是人機溝通最有效的方式？」它的子問題是「翻譯問題」，如何有效的將人類問題轉化爲可執行的指令。

核心問題是翻譯，將人類問題轉換為人類可以執行的指令。自然語言和 01 二進制機器語言之間需要大量的、連續的抽象中間層，它為人類提供了與硬件細節的緩衝，使我們能夠更直接地表達我們的意思。工具的選擇（如解釋器 interpretator 與編譯器 compiler）其實是對翻譯時誰承受「成本」的選擇。選擇用解釋器執行程序，那麼機器將需要多次重複執行同樣的程序，承擔計算資源的成本，但人類可以立刻看到執行結果；如果選擇編譯器，那麼人類需要提前寫好完整的代碼，承擔更高的認知負擔，但機器可以快速執行編譯後的二進制結果。

進步來自更好的語言和抽象，從而使人們可以更明確和安全地表達他們的意圖給機器。

（或許在 2025 年，這個問題已經得到很大程度的解決..？）

機器會思考嗎？

在探討人工智能的哲學問題時，我們首先需釐清，「AI」的定義已隨時代變遷。在1995年，Hamming 所討論的 AI，主要指電腦在智力領域對人類的輔助，例如協助音樂創作、化學合成路線的探索，這與我們在 2025 年所熟知的生成式 AI、大型語言模型（LLM）或 AI 代理（Agent）等概念有所不同。

儘管定義不同，一個核心的哲學問題至今仍然存在：「機器能夠思考嗎？」這個問題之所以複雜，根本原因在於我們所依賴的詞語本身就定義不清。例如，電腦處理的是「符號」（symbols），而非「資訊」（information），因為我們至今仍無法精確定義「資訊」到底是什麼，更不用說為它編寫程式。同樣地，「思考」的定義也充滿爭議，若我們將思考定義為「人類能做到而機器不能做到的事」，那這個問題就永遠不會有答案。

對於這個問題的立場，直接影響一個領域的領導者是否會積極採用新技術。Hamming 在書中提醒，抱持「機器不能思考」的偏見會讓你錯失良機，但若輕易相信「機器當然能思考」，則很可能陷入巨大的失敗。因此，關鍵不在於相信或不信，而是必須對這個議題有自己深入的見解。如今我們也深知，若不善用 AI 或相關工具，任何領域的發展都可能停滯，甚至被淘汰。

然而，即便 AI 應用已相當普及，許多哲學性的辯論仍未有定論：

• 機器能從經驗中學習嗎？ Art Samuel 的跳棋程式能透過與自己對弈來調整參數，最終擊敗州冠軍。這難道不算「從經驗中學習」嗎？若你認為這只是程式指令，那麼人類在課堂上被老師教導，不也是一種形式的「被編程」嗎？
• 機器是否具備原創性與創造力？ 一個幾何定理證明程式，為「等腰三角形兩底角相等」的定理，提出了一個連程式設計師都未曾想到的優雅證明。這份驚喜是「原創性」的展現嗎？這裡存在一個弔詭的悖論：一旦某個任務能被程式完成，人們就傾向於將其視為機械化的 rote process，從而否定了機器具備思考能力的可能性。

這種由機器帶來的驚喜，究竟是邏輯上全新的發現（Logical Novelty），還是僅僅是帶給人類的心理驚奇（Psychological Novelty）？Hamming 指出，程式的運行結果雖然時常讓程式設計師驚訝，但嚴格來說，這並非邏輯上的創新，因為一切仍在程式設定的範圍內。然而，人類的偉大發現，不也常常是基於過去經驗的累積，從而產生的心理驚奇嗎？

更進一步，「思考」是一個非黑即白的是非題，還是一個程度上的問題？或許我們不該只問「是否思考」，而是「思考到什麼程度」。

最後，我們該如何衡量思考？是根據產出的「結果」（what），還是執行的「過程」（how）？Hamming 觀察到，一個孩子在學習三位數乘法時，我們會感覺他「正在思考」；當我們成年人做同樣的運算時，感覺更像是「條件反射」；而當電腦執行時，我們完全不覺得它在思考。傳統的 AI 研究過度專注於「結果」，而忽略了「過程」也許才是思考的關鍵。如果一個程式能完成人類無法做到的複雜任務，例如設計百萬電晶體的晶片，這算是智慧嗎？或者，正因為程式是人類寫的，它的所有行為終究只是依循指令的機械化步驟？這些都是值得我們持續深思的難題。

定義的力量與限制

在資訊論被提出之前，人們對「資訊」的討論往往是空泛的。然而，一個清晰的定義能將模糊的直覺轉化為可以計算、測試和設計的具體限制，使我們能回答過去無法回答的問題。Shannon 的理論正是如此，它將通訊領域的模糊問題變成了可以尋求最佳解的工程問題，並嚴謹證明了可能性與不可能性的邊界，而過程中完全不涉及語義的討論。這是定義的力量。

然而，我們必須審慎檢視這個定義的內涵。首先，Shannon 並未定義資訊的「意義」，他只提供了一個度量它的公式。其次，這個度量完全基於「驚奇」（surprise）：一個事件的機率越低，它帶來的驚奇或資訊量就越大。這個概念雖然非常適用於電話、電腦等機器間的通訊系統，卻與人類對資訊的日常直覺不符。這也是為什麼貝爾實驗室的管理層最初希望稱之為「通訊理論」（Communication Theory）而非「資訊理論」的原因。第三，它是一個相對的度量，完全取決於你的知識狀態。例如，當你看著一串隨機數時，你會覺得每個數字都帶來驚奇；但若你知道生成這些數字的公式，那麼下一個數字就毫無懸念，也就不包含任何資訊。

Shannon 的例子揭示了一個普遍的現象：任何透過嚴格定義來形式化的概念，都不可避免地會扭曲人們對這個詞原來的直覺。長遠來看，這個被精確定義的詞彙，其意義將由定義本身所決定。一個非常著名的例子就是我們常說的 IQ：如果我們設計出一套測驗，並不斷修正使其內部一致，再透過校準使其分數呈現常態分佈，最後宣稱這就是對「智力」的測量，那麼這就是一個近乎完美的循環論證…

因此，我們應該培養一種審視基礎定義及其限制的思維風格，而不僅僅是學習技術。物理學家 Eddington 曾說過一個著名的故事：一群人用網子在海裡捕魚，在檢查漁獲後，他們得出結論：海裡的魚有最小尺寸的限制。這個結論顯然源於他們使用的工具（網子），而非真實的大海。定義也是一種工具，它決定了我們能「發現」什麼。Shannon 的「資訊」定義對於計算通訊系統的容量、極限和編碼方式極其強大，但它並非一套關於人類意義的理論。我們必須了解其適用範圍，並避免過度引申。

有關在計算模擬中的「garbage in, garbage out」

Garbage in, garbage out 這個古老的說法在計算模擬中總是對的嗎？事實上，這個觀念及其反面都可能是錯的。關鍵在於，我們必須判斷該系統是「收斂的」（convergent）還是「發散的」（divergent）。

發散系統對初始條件非常敏感，微小的誤差會隨著時間被急遽放大，導致結果天差地別。天氣預測就是一個典型的例子，日本一隻蝴蝶拍動翅膀的微小擾動，理論上可能最終決定了美國是否會發生風暴。在這種情況下，Garbage in, garbage out 的說法是成立的，因此要得到準確的結果極其困難。

收斂系統具有內在的穩定性，即使初始輸入的數據有很大的誤差（垃圾），系統的動態也會將其導向一個相對準確的結果。換句話說，大的誤差會隨著模擬的進行而變小。 比方说早期 NIKE 導彈測試中，兩枚測試導彈在飛行中途解體，原因不明。為了模擬失敗過程，團隊需要輸入導彈解體前的飛行數據，但當時的遙測數據模糊不清，他們只能用猜測的數值（也就是「垃圾」）作為初始條件。 然而，Hamming 意識到導彈的導引系統本身就是一個強大的反饋機制，會自動修正飛行軌跡的微小偏差，這形成了一個「強收斂的方向場」（strongly convergent direction field）。正因如此，儘管初始數據不準確，模擬最終依然成功重現了失敗過程，並揭示了問題的根源：工程師們忽略了俯仰（pitch）和偏航（yaw）之間的交互作用，導致能量不斷在兩者間轉移，最終使導彈失控。這正是「垃圾進，精準出」的絕佳範例。

這個原理就像貝爾實驗室 H.S. Black 發明的負反饋放大器一樣：只要反饋迴路中的增益極高，那麼整個放大器中只有一個關鍵電阻需要是高精度的，其餘大部分零件都可以是不準確的。系統的反饋特性會自動補償這些不精確之處。 因此，在進行或評估任何模擬之前，你都應該仔細審視這個根本問題：這個系統是穩定的還是不穩定的？這將決定模擬的可行性與結果的可靠性。

什麼是好的計算模擬？

一個可靠的計算模擬，其核心問題始終是：「為什麼我們應該相信這個模擬與現實相關？」在回答這個問題時，你不該被投入的人力、計算機的性能或問題的重要性等說辭所迷惑。這些都只是干擾 (distraction)，真正的答案應當立基於模型的健全性與計算的正確性之上。

要建立一個健全的模型，首先你需要領域專家對問題的深入理解。因為只有他們才知道模型中哪些因素是至關重要的，哪些可以被安全地忽略。許多模擬專家常犯的錯誤，就是認為自己可以獨立完成所有事，卻忽略了對應用領域的專業知識才是模擬準確性的基石。

與領域專家合作時，你需要精通領域所用的術語 (master the jargon) 。這主要是為了避免對基本概念的誤解。一個詞彙或數學符號，在不同的人腦中可能有截然不同的詮釋。你需要確保雙方對概念的理解完全一致，避免實現的時候出現歧義。

從實務角度（經濟、時間成本）來看，一個模擬專案之所以可行，通常是因為其中存在高度重複的計算部分。無論是計算原子彈中每個球殼的交互作用，還是天氣預報中每個空氣塊的變化，都是將同一套程式碼反覆應用。如果沒有這種重複性，單次模擬的程式設計成本將會高到無法負擔。

一個好的模擬要能夠幫助你從複雜系統中建立直覺。與其一開始就建構一個包羅萬象的複雜模型，你應該從一個只包含主要效應的簡單模型著手。在早期的 NIKE 導彈模擬中，正是因為使用了速度緩慢的類比計算機，研究人員才有充足的時間觀察、思考，從而「感覺」到導彈的飛行特性。這種直覺帶來了突破性的設計洞見，例如改用垂直發射和縮小機翼，這些是在大量高速運算的數據中難以發現的。先從簡化中獲得洞見，再逐步演化到更精細、完整的模擬，是一條更有效的路徑。

在評估一個模擬的可靠性時，你應該建立一套嚴謹的檢查清單來問自己或模擬的提供者：

1. 首先，背景場是否在很大程度上支持假設的法則？
2. 你對某些微小但重要的效應是否缺失的確定程度有多高？
3. 輸入數據是否可靠？
4. 模擬是穩定的還是不穩定的？
5. 針對已知的過去經驗，你有哪些交叉檢查可以檢查事物？
6. 你能否產生任何內部檢查，例如質量、能量或角動量的守恆？在沒有冗餘的情況下，正如你從錯誤更正代碼的講座中所知，可靠性上就不可能有檢查。

正如錯誤更正碼的原理一樣，如果系統中沒有任何形式的「冗餘」（redundancy），我們就無法對其可靠性進行任何有效的檢查。

「機會是留給準備好的人」

Luck favors the prepared mind

這句話承認了運氣的成分，但更強調成功在很大程度上取決於你自己。你時時刻刻都在透過自己的生活方式，選擇為成功做準備，或者選擇無所作為（人是習慣的總和）。

Hamming 舉了自己和同事 Shannon 的例子。他們在貝爾實驗室差不多同個時期，分別創立了Coding Theory 和 Information Theory。你可以說，這些想法「時機已到」(in the air)，這沒錯。但為什麼是他們，而不是當時也在那裡的其他人做到了呢？或許有些運氣，但更是因為他們的人格特質和思維模式，使他們比別人更有準備去發現、研究並創造出這些理論。如果偉大的成就主要靠運氣，那麼這些成就就不會反覆由同一群人達成。

愛因斯坦也是一個絕佳的例子。他在 12 到 14 歲時就問自己：「如果我以光速前行，光看起來會是什麼樣子？」他意識到自己會看到一個靜止的波峰，但當時的數學方程式卻不允許這種靜止的極值存在。這個矛盾早已在他心中埋下種子。多年後，當相對論的時機成熟，許多人都在研究相關問題時，正是因為這個早期思考，讓他比任何人都更懂得如何切入問題的核心。

牛頓曾說，如果別人像他一樣努力思考，也能做到同樣的事。愛迪生也說過：「天才是百分之一的靈感，加上百分之九十九的汗水。」偉大的創造，源於長年累月的辛勤努力，而非唾手可得。全然指望運氣，來度過你僅有一次的人生，是極其不智的。

那麼如何準備呢？總結全書，你需要

(1) 承認自己想做偉大的工作 (2) 厚實知識基礎，並不斷補充新知 (3) 培育你對自己的勇氣與信心 (4) 為自己設定願景，並用系統工程的方法實現它 (5) 讓重要的、對的問題浸染你的潛意識，讓你在夢中持續咀嚼問題 (6) 關心你所在乎領域的世界大局，並不斷預測之

Introduction

This book is a compilation of the course Richard Hamming taught at the Naval Postgraduate School in 1995. Its core starting point is that “A life without a struggle on your part to make yourself excellent is hardly a life worth living,” its core claim is “Luck favors the prepared mind,” and its core content is the author’s introspection on his own distinguished research career, plus his observations of famed Bell Labs colleagues (Claude Shannon, John Tukey, etc.), to answer how to become a prepared mind (as a style of thinking).

Another central aim is to inspire you to find your own style of thinking and set a mission and direction. You must think, and you must accomplish something meaningful that transcends yourself. For example, a drunken sailor’s random walk covers an average distance of \sqrt{n}, but if a beautiful girl stands in some direction, the sailor’s average distance becomes proportional to n. Hamming also observes that whether your initial vision is “right” doesn’t matter much. There are many paths to excellence, and any of them beats drifting with the tide.

In other words, this book tries to prepare you for your future. By 1995 Hamming had already observed that technological progress was accelerating and knowledge was iterating ever faster, i.e. half of what you learned 15 years earlier might already be obsolete. Yet the future still holds infinite opportunities, so he shows how he reasoned from first principles to anticipate nascent fields (fiber optics), how a deep grasp of binary mathematics enabled him to invent world‑changing technology (error‑correcting codes), how to research effectively without “fully understanding” (quantum mechanics), how to build with a systems‑engineering mindset, and how to extract design insights from simulation (NIKE missile). His answer to “how to cope with the rapid technological change” is learning to learn—the book’s subtitle.

The target audience was the students at the Naval Postgraduate School, but I think it speaks to anyone who aims to make a significant contribution in a technological society, especially scientists and engineers (undergrads and graduate students). Two reasons: first, you need to feel a professor’s encouragement to pursue excellence; second, you need guided, systematic exposure to the thinking and methods showcased above.

The book leads readers across multiple highly technical modern research areas to extract the “style of thinking” the author emphasizes. Hence it contains hard‑core topics like information theory, coding theory, and digital filters etc.

When choosing a vision/direction, you will inevitably have to answer these three questions:

1. What is possible? (Science)
2. What is likely to happen? (Engineering)
3. What is desirable to happen? (Ethics)

These future‑facing questions are hard. Our only guide is history, and because computers are transforming every field, the history of computing becomes the backbone context of the book.

Across all topics, the distinction between education and training runs through the chapters and is a key separator of leaders from followers. Once you enter a field, you are either a leader or a follower, and Hamming wants you to be a leader.

Reading suggestions

I’d recommend reading “You and Your Research” first with a mindset of reading a blog (30‑minute read) to feel Hamming’s hopes for the next generation. If you’re interested in this book, I suggest splitting it into blocks, then reading each block as a blog or series. For instance, History of Computers is a series; AI is a series; Coding Theory and Information Theory is a series; Simulation is a series. Others, like System Engineering, read more like single posts. Each “series” or “post” has meta points—focus on understanding those meta points, not on exhaustive technical details and anecdotes.

Below I piece together my selected notes I found useful or interesting; for the full version please check this whiteboard.

Education vs Training

Education is what, when, and why to do things. Training is how to do it.

From a systems‑engineering perspective, training teaches students to solve a well-defined problem, i.e. what technique fits which situation and how to apply it. Education prepares students to face ambiguous problems: to iteratively frame the problem using knowledge from multiple courses and then choose suitable techniques to solve it.

For leaders in a technological society, what, when, and why to do things matter more than how (though it still matters). Hamming reminds us: “What you learn from others you can use to follow; what you learn for yourself you can use to lead.” The real purpose of education is to cultivate vision, judgment, and self‑correction, such that when faces with uncertainty, you will will have the ability to choose a direction and adjust your path along the way. In a world with a rapidly shrinking half‑life of knowledge, education should focus on “preparing for the future,” not clinging to the details of “how”.

From the fitness point of view, lifting 40 kg twice usually grows more muscle than lifting 20 kg four times. Does this “physical muscle” training apply to “mental muscles”? They aren’t perfectly equivalent, but the analogy could be useful: deep cognitive challenges prepares you better than shallow repetitions.

For learning and day‑to‑day thinking, Hamming suggests:

• Build deep foundations: technical details iterate rapidly; fundamentals transfer across eras.
• Learn new things continually: knowledge grows exponentially; you must proactively track emerging fields.
• Model quickly: do back‑of‑the‑envelope calculations, use quick mathematical modeling to estimate and test claims.
• Regularly think about big questions: spend an afternoon each week (about 10% of work time) on forward‑looking, open problems. For example, “What is the nature of computing? How will it affect science? What is the natural role of computers at Bell Labs? What will computers do to AT&T? To science at large?” This clarifies where humanity is headed so you can move in the right direction, thus avoiding the drunken sailor’s \sqrt{n} meander and progressing more linearly. It also keeps attention on the crucial problems so your main effort goes where it matters.

The invention of error‑correcting codes

Error‑correcting codes transformed communication and storage, enabling automatic error detection and correction under noise at very low redundancy. It’s a bedrock of modern technology.

One of the main reasons Hamming discovered error-correcting codes was that he was repeatedly frustrated by machine failures caused by coding errors. Machines would stall because a 0 flipped to 1 or vice versa. After repeated schedule slips from such failures, he got angry and asked: “If machines can detect errors, why can’t they locate them and automatically fix them?”

He knew you could store three copies of the code and vote to correct errors, but the code redundancy was too expensive (memory was precious). He knew there had to be a better way so he started working on this. His understanding of two‑out‑of‑five codes, parity checks, and binary arithmetic was decisive. At the time, most scientists and engineers weren’t comfortable with binary; people still favored decimal, unlike today where binary is the natural language for computing.

Hamming’s key insight in inventing error‑correcting codes was a simple yet profound one: treat the detected error “syndrome” itself as a binary number, and that number points directly to the position where the error occurred. Building on that, he went on to propose that, to intuitively explore the power and limits of binary codes, one should shift the metric space for measuring code distance from the traditional Euclidean space to the binary metric of Hamming space, thereby establishing an entirely new geometric framework for designing and analyzing error‑correcting codes.

True creativity comes from a subconscious saturated by the problem

“Originality” isn’t just “never done before.” You can multiply two random ten‑digit numbers, but that has no meaningful consequence. Creativity seems to be combining elements not previously seen as related in a “useful” way, which is often hinging on the initial psychology distance between them (as with choosing Hamming distance rather than Euclidean distance for comparing bit strings).

Can people become more creative? Most creativity courses and tools on the market don't seem particularly helpful, because they never produce a large number of dominant figures in any field. Throughout the book, creativity is called "style," and Hamming believed people can become more creative. A creative act usually begins with a vaguely conscious identification of a problem, followed by a process of converging on the problem. During convergence, don't frame it too quickly, because you'll put it into a conventional form and get conventional conclusions. At this stage, a deep emotional commitment is needed to truly engage. Long incubation of the problem can lead to temporary solutions or a temporary abandonment of the problem. This is the common process behind many great creative acts, and it is essential for letting the subconscious think about the problem.

Next comes the moment of insight or “creativity.” Wrong starts and wrong solutions often make your next attempt sharper. Now you know which approaches are wrong! There are fewer directions left to explore. You gain a better understanding of what doesn’t work and why it might not work.

If the solution comes from the subconscious, then we can saturate the subconscious with the problem. If we stop thinking about anything else for hours, days, or even weeks, we may even chew on the problem in our sleep! Luck favors the prepared mind, and you can be prepared.

During the creative process, reasoning by analogy is one of the most important tools, therefore broad knowledge across different fields helps a great deal, provided that knowledge can be accessed flexibly. That depends on studying new material from multiple angles and building many “knowledge hooks” for it. That way, when needed, you can hook that crucial idea out of your mind by analogy.

If you don’t work on important problems, how can you expect to do important work?

(From You and Your Research)

“It seems to me it is better to do significant things than to just get along through life to its end. Certainly near the end it is nice to look back at a life of accomplishments rather than a life where you have merely survived and amused yourself. (1) it is worth trying to accomplish the goals you set yourself, and (2) it is worth setting yourself high goals.”

So admit boldly: “I want to do first‑class work!” If you do not work on important problems how can you expect to do important work?

Many excuse themselves with “I’m not smart enough,” but many who didn’t look like geniuses did great things. At Bell Labs, Bill Pfann didn’t seem especially brilliant at first, yet his work on zone melting won all the prizes in the field; as his confidence grew, he became more articulate. Ability comes in many forms, not just IQ.

Confidence, perhaps more than high IQ, is the more critical trait, which you could also call "courage." This courage can be cultivated through focus on your successes and less concern for your failures. Claude Shannon, for example, would often boldly put his queen on the line in chess, saying, "I ain't scared of nothing." When you find yourself in a difficult situation, you might tell yourself the same thing.

With ambition and courage, the next step is to ensure you are spending your energy on the "right" problems. To do this, you should regularly set aside time to think about the bigger "great ideas": What is the essence of your field? How will it affect the development of science? If you want to be a leader rather than a follower, you must break free from the sea of details that most people are trenched in and constantly examine the big picture. One concrete method is to keep a running list in your mind of about 10 to 20 important problems that you care about but don't yet know how to solve. Great scientists do this; they keep these problems in mind, and when a clue appears, they would dive in immediately.

The desire for excellence is a fundamental characteristic of great work. Without such a goal, you will wander aimlessly like a drunken sailor (averaging to ( \sqrt{n} )).

How to watch an emerging field and prepare for it

How should we approach a new emerging field with great potential? Using the rise of fiber optics technology as an example from his personal experience, Hamming explained his thinking process for dealing with a completely new field.

First, Hamming started from "first principles" to quickly identify the importance of fiber optics. The principles of physics revealed that optical frequencies are much higher than the electrical frequencies used at the time, thus offering greater bandwidth. Moreover, its raw material is sand, which is everywhere, making its cost advantage obvious compared to the increasingly scarce copper ore. Additionally, he noticed that the conduits for telephone lines in Manhattan, New York, were nearing saturation. If the city were to continue developing, fiber optics, with its smaller diameter, was the only solution that wouldn't require massive street excavations. These reasons convinced him that his employer, Bell Labs, would go all out to invest in this technology.

Next, he continuously tracked the technical bottlenecks he foresaw and updated his knowledge as the field evolved. For instance, he realized early on that "how to splice hair-thin optical fibers" would be a major practical challenge. He also observed that existing systems needed to convert optical signals to electronic signals for amplification and then back to optical signals, which he considered a poor design. He foresaw the inevitable emergence of "optical amplifiers." Furthermore, he realized that fiber optics are immune to electromagnetic interference (such as from nuclear explosions or lightning strikes), meaning they would certainly receive strong support from the military. By focusing on these key issues, the development roadmap of the entire field became clearly visible to him.

You should always proactively ask questions to better predict and lead the future, rather than passively following trends.

Education and Training in the Computer Age

During the development of computers, numerous educational studies indicated that computers were beneficial for education and could assist in training students. However, most educational experiments failed to address the "Hawthorne effect"—a temporary improvement in performance due to the perception of receiving special attention or observation. Most of the efficiency gains observed with new learning methods typically reflect this bias rather than substantial improvements.

The standards of higher education have been constantly changing. Future education will be vastly different from present education, just as present education is almost irrelevant to that of nineteenth century. Educational systems will leap forward dramatically with technological advancements. How can we evaluate proposed CAI (computer-aided instruction) projects without an appropriate vision for the future form of education? We must establish a vision for what educated individuals in future society will look like; only then can we confidently address the issues that arise in CAI.

Hamming believed that computers are helpful for low-level, conditioned responses (like arithmetic drills, flight training) but less useful for education, partly because, as mentioned, we don't yet know what it means to be "educated" in the new era. (In 2025, Andrej Karpathy of Eureka Labs has something to say.)

To what extent is what we teach/learn training, and to what extent is it education?

Systems engineering

The core philosophy of systems engineering is to constantly focus on the macro-objective and transform local actions into overall results.

The fundamental difference between a systems engineering perspective (system view) and an executor's perspective (task view) lies in "I am building a cathedral" versus "I am carving a stone." Many people mistakenly believe they understand this, but most of the time, they are still immersed in details without considering the bigger picture. Therefore, a systems engineer should be evaluated based on what they produce instead of what they say.

The first rule of systems engineering is: "If you optimize small components, you are likely to ruin the performance of the system." If you focus on optimizing a simple component without considering its impact on the overall objective, you will ruin the overall objective. There are examples of this in engineering, but a more easily relatable example is education: if you constantly look for shortcuts in school (e.g., cramming before tests), your school education will be a failure.

A systems engineering approach to education is to have students pass a comprehensive exam covering nine courses based on their major. In this case, when taking any course, the focus is not on passing the course or pleasing the professor, but on learning the course content so that you will still remember the important knowledge from the course at some later time (2 years later). After all, what matters in your education is what emerged at the end, and what happens at each stage is not as important.

The second rule of systems engineering is that the design must be flexible, prepared for change, and ensure smooth transitions when adjustments are made without compromising the functionality of other parts. The half-life of technical knowledge is about 15 years, which means that many of the details learned today may no longer be applicable in the future. Therefore, the goal of education should be to prepare you for your future, focusing more on fundamental principles rather than changing details.

The third rule of systems engineering is that the design should "gracefully degrade" when overloaded. If a design is too close to its specifications, its failure will be rapid and catastrophic when the load exceeds expectations, much like a bridge designed for a specific load or a telephone system designed for maximum traffic. A good system, however, will gradually degrade in performance when the stress exceeds its limits, rather than collapsing outright.

Systems engineering is a never-ending task. First, the emergence of any solution changes its environment, thereby creating new problems. Second, the process of solving a problem often gives the engineer a deeper insight into the problem itself, leading to dissatisfaction with the existing solution. In systems engineering, there is no such thing as a "final answer" because every solution should provide new insights for the next round of improvements. A solution that does not bring new insights can hardly be called a solution. Therefore, the core of systems engineering is to accept the fact that both problems and solutions are not static; evolution is the norm.

School education typically provides well-defined problems and a single correct answer, but real-world systems engineering work is the opposite. It begins in a chaotic, ambiguous context, requiring engineers to shape a workable solution from it. Hamming believed that the best way to learn systems engineering is to contrast the idealized solutions learned in the classroom with complex real-world situations. The goal of systems engineering is to correctly solve the "right problem," even if the solution itself may not be perfect. Every solution is temporary, but the deep understanding it brings paves the way for the next design iteration.

You Get What You Measure

"Measurement" here refers not only to numbers but to all systems of setting indicators: educational objectives, hiring criteria, performance evaluations, and promotion mechanisms. The tools you use for measurement shape your perception, much like a fisherman inferring a minimum fish size based on the mesh of his net. Design every metric with careful consideration for its second and third order effects.

For example, we can look at how scoring systems influence risk-taking:

• Suppose everyone begins with a score of 95%. There is little room for improvement, but any mistake lowers the score, making risk avoidance the rational strategy. Leadership may desire bold leaders, but promotions ultimately favor shrewd risk-avoiders.
• If the starting average is 50%, behavior tends to be more balanced. To encourage innovation, start at 20% (or lower). The cost of failure is small, while the upside from success is large, motivating people to try. If you want true risk-takers in leadership positions, reward risk-taking early in the evaluation and promotion process.

Short-term indicators for admissions, hiring, or promotions may not reflect your long-term goals. In mathematics and computer science, early selection favors reliable execution of certain mental ability (e.g., cracking leetcode hard). However, later on, the ability to grasp the big picture and predict important new results becomes more important. Similarly, in recruitment, traits that are attractive to a typical recruiter may not be suitable for the right candidate, which is why researchers at Bell Labs do recruitment themselves.

The accuracy of measurement is often confused with the relevance of measurement. For example: measuring "training" is easy, while measuring "education" is difficult. Another classic example is IQ tests. The design and calibration of these tests are inherently intended to make their score distributions conform to a normal curve. Therefore, the conclusion that "intelligence is normally distributed" is less a reflection of the true nature of intelligence than an artificial result created by the measurement methodology itself.

In any organization, you need to be aware of one fact: people will optimize around the metrics you set, rather than toward your original intentions when setting those metrics. Employees at all levels will find ways to make their themselves look good. Worse still, the meaning of metrics becomes distorted as it is transmitted across different hierarchical levels. For example, a lower level operator's assessment report on "organizational capacity" might be misinterpreted at the executive level as the "probability" of success.

When metrics change, behavior adjusts accordingly. Military formal inspections have taught units how to "perform" combat readiness; regular inspections are deliberately prepared for, and even supposedly "random" spot checks are often anticipated in advance. Business or war game training often teaches leaders how to win simulated competitions rather than how to meet real-world challenges. Therefore, when designing any measurement system, you cannot only consider its first-order effects; you must also anticipate and respond to the second-order and even higher-order behavioral responses it will trigger.

Insights from High-Dimensional Space on Complex System Design

When we design a complex system, if we consider all available parameters, it is equivalent to searching for an optimal solution in an n-dimensional space. But when the dimension n becomes very large, where is the main body of this design space located? Is it on the "surface" of this n-dimensional sphere, or in its "interior"? The answer to this question provides important insights for how we search for the best design.

To answer this question, we can compare the volume of the thin shell on the outermost layer of an n-dimensional sphere with the proportion of the total sphere volume. Assuming the sphere has a radius of r, and we consider a sphere with inner radius r(1-\epsilon), then the proportion of the volume of the outermost thin shell to the total volume is:

This indicates that the sphere's volume is almost entirely concentrated in the thin shell near the surface. For example, if we consider the outer half of the radius range (i.e., \epsilon = 1/2), in three-dimensional space (n=3), this thin shell accounts for 1 - (1/2)^3 = 7/8 of the total volume. As the dimension n increases, the ratio 1 - (1/2)^n rapidly approaches 1.

In other words, the optimal design almost certainly lies on the "surface" of the feasible region, rather than in its "interior". This may contradict the optimization methods we learned in basic calculus courses, because those methods typically search for extrema in the interior. However, in high-dimensional spaces, the optimal solution often involves pushing one or more design parameters to their allowable limit values, which naturally means we are on the boundary of the design space.

The timelessness of FORTRAN

In computers, the meaning of an instruction derives from its execution process; the symbol itself have no intrinsic meaning. This is what we call "Semantics comes from implementation." In other words, it is the subroutines written to perform specific operations that define the true meaning of a program.

In the very early era of computing, program control was extremely dependent on human intervention. From desktop calculators to punch card machines controlled by plug boards, then to paper tape and ENIAC's initial control through complex wiring, all of these exemplified this dependency.

To simplify program design, a group of scientists invented symbolic abstraction, such as letting the three letters ADD automatically become machine code like 1011 in binary during compilation. Interestingly, the emergence of this Symbolic Assembly Program (SAP) was viewed by hardline programmers of the time as heretical—"sissy stuff"—which they disdained to use.

Building on the foundation of SAP, John Backus and his team proposed FORTRAN (short for Formula Translation) in the 1950s. Hamming's experience was that after his programmers adopted FORTRAN, their output efficiency improved 10x. However, the professional programmer community of the time widely resisted it, for three main reasons: first, they believed it was impossible to implement; second, even if it could be done, it would extremely waste precious machine time and storage capacity; and third, even if it truly worked, no self-respecting programmer would deign to use it.

FORTRAN eventually became widespread and has withstood the test of time, while many later languages, such as Algol, failed. The fundamental reason of FORTRAN's success lies in its design being more aligned with human psychological intuition. It can directly translated mathematical formulas that people had already become accustomed to in school into programs, without requiring the learning of an entirely new way of thinking. In contrast, Algol, designed by logicians, was more rigorously elegant in logic but ultimately became obsolete due to its lack of human-centric design. This demonstrates that designs aligned with human psychology have far greater vitality than those based on pure logic.

This means that whether a tool can have a profound impact on humanity and withstand the test of time depends on whether it is sufficiently aligned with human nature.

Human-Computer Communication

The core problem of most modern software still remains: "What is the most effective way for human-computer communication?" Its sub-problem is the translation problem, “how to effectively convert human problems into executable instructions?”

Between natural language and binary machine language, there needs to be a substantial number of continuous abstract intermediate layers, which provide humans with a buffer from hardware details, enabling us to express our meaning more directly. The choice of tools (such as interpreters versus compilers) is essentially a choice about who bears the "cost" during translation. If you choose to execute programs with an interpreter, the machine will need to repeatedly execute the same operations, bearing the computational resource cost, but humans can immediately see the execution results; if you choose a compiler, humans need to write complete code in advance, bearing a higher cognitive burden, but the machine can rapidly execute the compiled binary results.

Progress comes from better languages and abstractions, enabling people to express their intentions to machines more clearly and safely.

(Or perhaps by 2025, this problem has already been largely solved..?)

Do machines think?

When exploring the philosophical questions of artificial intelligence, we must first clarify that the definition of "AI" has evolved over time. In 1995, the AI that Hamming discussed primarily referred to computers assisting human intelligence in intellectual domains, such as helping with music composition or exploring chemical synthesis routes. This is quite different from the concepts we are familiar with in 2025, such as generative AI, large language models (LLMs), or AI agents.

Despite these definitional differences, a core philosophical question persists to this day: "Can machines think?" The complexity of this question stems fundamentally from the fact that the words we rely on are themselves poorly defined. For example, computers process "symbols" rather than "information," because we still cannot precisely define what "information" actually is, let alone write programs for it. Similarly, the definition of "thinking" is highly controversial. If we define thinking as "something humans can do that machines cannot," then this question will never have an answer.

One's stance on this question directly influences whether a leader in their field will actively adopt new technologies. Hamming reminds us in his book that harboring the bias that "machines cannot think" will cause you to miss opportunities, but if you too readily believe that "of course machines can think," you are likely to encounter enormous failures. Therefore, the key is not whether to believe or disbelieve, but rather to have your own deep insights into this issue. Today we also clearly understand that if we fail to effectively use AI or related tools, development in any field may stagnate or even become obsolete.

However, despite the widespread application of AI, many philosophical debates remain unresolved:

• Can machines learn from experience? Art Samuel's checkers program was able to adjust its parameters through playing against itself and eventually defeated a state champion. Doesn't this count as "learning from experience"? If you argue that this is merely program instructions, isn't a human being taught by a teacher in a classroom also a form of being "programmed"?
• Do machines possess originality and creativity? A geometric theorem-proving program proposed an elegant proof for "the base angles of an isosceles triangle are equal" that even the program's designer had never thought of. Is this surprise an expression of "originality"? Here lies a curious paradox: once a task can be completed by a program, people tend to view it as a mechanical rote process, thereby denying the possibility that machines possess the ability to think.

Is this kind of surprise brought by machines a logically novel discovery (Logical Novelty), or merely a psychological novelty for humans (Psychological Novelty)? Hamming points out that although program execution results often surprise programmers, strictly speaking, this is not a logical innovation because everything remains within the scope of what the program was designed to do. Yet, don't the great discoveries of humanity also often arise from the accumulation of past experience, producing psychological novelty?

Going further, is "thinking" a binary yes-or-no question, or is it a matter of degree? Perhaps we shouldn't only ask "whether thinking occurs," but rather "to what degree does thinking occur."

Finally, how should we measure thinking? Based on the "result" (what), or the "process" (how)? Hamming observes that when a child learns three-digit multiplication, we feel he is "thinking"; when we adults do the same calculation, it feels more like "conditioned reflex"; and when a computer executes it, we don't feel it's thinking at all. Traditional AI research has overemphasized "results" while overlooking that "process" might be the key to thinking. If a program can accomplish complex tasks that humans cannot, such as designing a chip with a million transistors, does that count as intelligence? Or, precisely because the program was written by humans, are all its behaviors ultimately just mechanical steps following instructions? These are challenging questions worthy of our continued contemplation.

The power and limits of definitions

Before information theory was proposed, discussions about "information" were often vague and abstract. However, a clear definition can transform fuzzy intuitions into concrete constraints that can be calculated, tested, and designed with, thus allowing us to answer questions that were previously unanswerable. Shannon's theory exemplifies this: it transformed vague problems in communications into engineering problems where optimal solutions could be sought, and rigorously proved the boundaries of possibility and impossibility, all without touching on semantics. This is the power of definition.

Yet we must carefully examine the implications of this definition. First, Shannon did not define the "meaning" of information; he merely provided a formula to measure it. Second, this measurement is based entirely on "surprise": the lower the probability of an event, the greater the surprise or information it carries. While this concept works extremely well for communication systems between machines like telephones and computers, it conflicts with how humans intuitively understand information in daily life. This is why Bell Labs' management initially wanted to call it "Communication Theory" rather than "Information Theory." Third, it is a relative measure entirely dependent on your state of knowledge. For instance, when you look at a string of random numbers, you might feel each digit brings surprise; but if you know the formula generating these numbers, the next digit holds no mystery and contains no information.

Shannon's examples reveal an universal phenomenon: any concept formalized through rigorous definition inevitably distorts people's original intuitions about that word. In the long run, the meaning of this precisely defined term will be determined by the definition itself. A famous example is what we commonly call IQ (as discussed before): if we design a test, continuously refine it for internal consistency, calibrate it so scores follow a normal distribution, and then claim this measures "intelligence," we have essentially constructed an almost perfect circular argument.

Therefore, we should cultivate a thinking style that critically examines foundational definitions and their limitations, rather than merely learning the techniques they enable. Physicist Eddington once told a famous story: a group of people fish in the sea with nets, and after checking their catch, they conclude that fish in the sea have a minimum size limit. This conclusion obviously stems from their tools (the nets) rather than the actual ocean. Definitions are also tools, they determine what we can "discover." Shannon's definition of "information" is extremely powerful for calculating communication system capacity, limits, and coding schemes, but it is not a theory about human meaning. We must understand its scope of applicability and avoid over-generalization.

On “Garbage In, Garbage Out” in Simulations

Is the old saying "garbage in, garbage out" always true in computational simulations? In fact, both this principle and its opposite can be wrong. The key lies in determining whether the system is "convergent" or "divergent." (or stable vs unstable)

Divergent systems are extremely sensitive to initial conditions. Small errors are rapidly amplified over time, leading to dramatically different results. Weather prediction is a classic example. In theory, the minute fluttering of a butterfly's wings in Japan could ultimately determine whether a storm occurs in the United States. In such cases, "garbage in, garbage out" holds true, and obtaining accurate results is extraordinarily difficult.

Convergent systems possess inherent stability. Even when initial input data contains large errors (garbage), the system's dynamics will guide it toward a relatively accurate result. In other words, large errors become smaller as the simulation progresses. Consider the early NIKE missile tests, for example: two test missiles disintegrated mid-flight for unknown reasons. To simulate the failure process, the team needed to input the missile's flight data before disintegration, but the telemetry data from that time was unclear. They could only use guessed values (garbage) as initial conditions. However, Hamming realized that the missile's guidance system itself was a powerful feedback mechanism that automatically corrected small deviations in flight trajectory, forming a "strongly convergent direction field." Because of this, despite the inaccurate initial data, the simulation ultimately succeeded in reproducing the failure process and revealed the root cause: engineers had overlooked the interaction between pitch and yaw, causing energy to continuously transfer between the two, ultimately causing the missile to lose control. This is an excellent example of "garbage in, precision out."

This principle is similar to the negative feedback amplifier invented by H.S. Black at Bell Labs: as long as the gain in the feedback loop is extremely high, only one critical resistor in the entire amplifier needs to be high-precision; most other components can be inaccurate. The system's feedback characteristics automatically compensate for these imprecisions. Therefore, before conducting or evaluating any simulation, you should carefully examine this fundamental question: is the system stable or unstable? This will determine both the feasibility of the simulation and the reliability of its results.

What makes a good simulation?

At the heart of a trustworthy simulation is always the question: "Why should we believe this simulation is relevant to reality?" When answering this question, you should not be distracted by arguments about the authorities invested, the computer's performance, or the importance of the problem. Those are merely distractions; the true answer must rest on the soundness of the model and the correctness of the computation.

To build a sound model, you first need domain experts with deep understanding of the problem. Only they know which factors in the model are critical and which can be safely ignored. A common mistake many simulation specialists make is believing they can do everything on their own while overlooking that domain expertise is the foundation of simulation accuracy.

When collaborating with domain experts, you need to master the domain's jargon. This is primarily to avoid misunderstandings of basic concepts. A word or a mathematical symbol can be interpreted very differently in different minds. You must ensure both sides have exactly the same understanding of concepts to avoid ambiguity during implementation.

From a practical (economic and time cost) perspective, a simulation project is usually feasible because it contains highly repetitive computational parts. Whether calculating interactions for every spherical shell in an atomic bomb or the changes of every air parcel in a weather forecast, the same code is applied repeatedly. Without this repetitiveness, the programming cost for a single simulation would be prohibitively high.

A good simulation should help you build intuition about a complex system. Rather than starting with an all-encompassing complex model, you should begin with a simple model that contains only the primary effects. In the early NIKE missile simulations, it was precisely because researchers used slow analog computers that they had enough time to observe and think, thereby "feeling" the missile's flight characteristics. That intuition led to breakthrough design insights such as switching to vertical launch and reducing wing size that are hard to find buried in large amounts of high-speed computation. Gaining insight from simplification first, then gradually evolving to more refined, complete simulations, is a more effective path.

When evaluating the reliability of a simulation, you should establish a rigorous checklist to ask yourself or the simulation provider:

1. Does the background field largely support the assumed laws?
2. How certain are you that you have not omitted some small but important effects?
3. Are the input data reliable?
4. Is the simulation stable or unstable?
5. What cross-checks do you have against known past experience?
6. Can you generate any internal checks such as conservation of mass, energy, or angular momentum? Without redundancy, as you know from lectures on error-correcting codes, there can be no checks on reliability.

As with the principles of error-correcting codes, if there is no form of "redundancy" in the system, we cannot perform any effective checks on its reliability.

“Luck favors the prepared mind”

This saying acknowledges the element of luck, but emphasizes that success largely depends on yourself. At every moment you are, through the way you live, choosing either to prepare for success or to do nothing (people are the sum of their habits).

Hamming gives the example of himself and his colleague Shannon. They worked at Bell Labs around the same time and respectively founded Coding Theory and Information Theory. You might say those ideas were "in the air". That’s true, but why them, and not others who were there then? Perhaps some luck, but more importantly their personalities and ways of thinking made them better prepared than others to discover, study, and create those theories. If great achievements were mainly due to luck, they would not repeatedly come from the same small set of people.

Einstein is another example. Between ages 12 and 14 he asked himself: "If I rode alongside a beam of light, what would the light look like?" He realized he would see a frozen wave crest, yet the mathematics at the time did not permit such a static extremum. That contradiction planted a seed in his mind. Years later, when the time for relativity came and many people were investigating related problems, it was that early thinking that put him in a position to understand how to get to the heart of the matter better than anyone else.

Newton said that if others had thought as hard as he did, they could have done the same. Edison also said, "Genius is one percent inspiration and ninety-nine percent perspiration." Great creations arise from long years of hard work, not from things handed to you. Relying entirely on luck to get through the single life you have is extremely unwise.

So how do you prepare? Summarizing the whole book, you should

(1) Acknowledge that you want to do great work (2) Build a deep knowledge foundation and learn continually (3) Cultivate courage and confidence in yourself (4) Set a vision for yourself and system-engineers towards it (5) Let important, right problems saturate your subconscious so you keep chewing on them even in your dreams (6) Care about the big-picture state of the world in your field and continually make predictions

我之前覺得最重要的三件事是 Build, Learn and Source，但經過了幾個月瘋狂 build, learn 和 source 後，我現在覺得 learn 才是最重要的。因為純 build 越來越簡單了，而 source 則需要品味幫忙篩選。

七月以來，我花了很多時間在 build 一些自己覺得有趣的想法、接的案子上，learn 需要用到的技術概念與細節、以及做好 source 機會這件事。從數據上來講，我 merge 了 103 個 PR，學了一堆軟體開發概念，與 5 家公司進行了超過 11 場面試。

這段經驗告訴我，實現一個軟體層面的想法是一件容易的事情，而且就現在 AI 進步的趨勢來看，這只會越來越容易。但實現一個值得被創造出來、能對世界造成符合自身價值影響的東西，依舊是十分困難的。

簡單說一下為什麼我認為「實現軟體是簡單的事情」。一年前我想到在軟件裡面添加登入、註冊系統、收費系統等，我會覺得高不可攀，一方面是因為我對這些流程和技術不熟悉，另一方面之前用 AI 寫程序出錯率還是特別高。但最近除了 AI 能力強得離譜之外，越來越多工具在系統設計層面直接幫你解決這些問題，讓你只需要在乎功能和頁面設計，不需要擔憂傳統來說繁複的後端系統。比方說 Convex.dev 就是一個 reactive database，它可以幫你解決 database、backend 的整合問題，還有 type-safety 的問題等。Convex 的用戶甚至還可以用幾行代碼引入它所提供的 OAuth integration，讓 Google 登入、Discord 登入、Sign in with Apple 等的工程任務化為去官網獲得 OAuth 相關數據證書的 operational task。

就算你不用 Convex 這類的後端集成平台，將本地的服務部署到服務器也是十分簡單的任務。你只需要用一個有 AI 能力的 terminal，比如 Cursor、Warp.dev，或在 Terminal 裡面打開 Claude Code、Codex CLI，你就能直接請 AI 讓它幫你部署到 Vercel、Fly.io 等 PaaS 平台。你也可以直接租一個 VPS，然後在裡面安裝 Claude Code，然後把整個 DevOps 交給它。

Lovable、Base44、Vibeflow、Bloom.diy 等 vibe-coding 產品如今也都自帶後端系統。創造一個全棧軟體從沒有那麼容易過。

創造變的容易，但這些創意都是有價值的嗎？從滿足創造慾的角度來講，對當下的自己有價值。但創造出來後，我會去用嗎？別人會去用嗎？有這個和沒這個對人類來講有差嗎？不一定。X 和 小紅書上面每天都會刷到很多新的、募資百萬千萬美元的初創公司，但有多少公司的產品是真的值得被創造出來的？有多少只是噪音？

在大約確認自己在勞動力市場上的價值後，我最近的主要方向改為閱讀、研究一些自己感興趣的課題，希望從中感受不同領域的課題對我的吸引力，逐步建立自己對世界更完整的理解和品味。至於之後要幹嘛，我覺得我學一段時間後就會想到了。

如果創造變得容易，那麼對世界的想像力，以及對價值判斷的品味才是重要的，而獲得這些最快的方法果然還是多學習吧！

有關上篇文章中的 “the opportunity cost of not building has never been higher”的觀點，我現在的想法是，如果你的想法本身沒用，那不把它是實現出來其實也沒有什麼損失 :D

相關閱讀：You Are Moving Out Of Your Reference Class

這篇文章講的是技術讓創造變得容易，因此你應該要更大膽，更有野心一點。

---

Most of this month I’ve been working on a contract AI-engineering project, I implemented sign-in-with-apple, iOS in-App purchase, sign-in-with-wechat (OAuth), account linking, revamped some UI/UX on iOS app; submitted the iOS app to App Store Connect and resolved four review cycles; I also surveyed, selected cloud vendors and migrated existing backend and database servers from HongKong to Beijing.

Throughout the month, I shipped PRs, and Leo reviewed it. Leo is an ex-Amazon engineer, and a friend/mentor of mine. This is the first time I’m collaborating with someone with a lot more engineering expertise than me.

(Note: my responsibility on this project is primarily execution. We align on priorities and checkpoints, and I carry them through to deliver the agreed results.)

As someone junior in Engineering, I received lots of feedback, and here are some of my reflections.

When designing systems, optimize for what we actually care about

It’s all about identifying what we care most about and system engineer towards that. Systems engineering is about asking, at each step, how our decisions are helping us get to what we care about. In our case, we want to ship it quickly and get done with it, but we also want to be able to maintain it easily after our development. So Leo and I had lots of discussions around how to better design the database schema and related system (dev/prod env). Being able to identify tradeoffs for each decisions becomes even more critical.

Read what the LLM wrote

You can’t skip reading what LLM coded, otherwise prepare for spaghetti code. Almost always, claude will over-engineer and make the codebase a lot harder to understand. Always be ready to ask if it over-engineered. There are often moments when I can’t tell if it over-engineered, and that’s when I know I have limited knowledge on the subject. I rely a lot more on seniors and talking to models to learn here.

Doc‑driven coding

Engineering is changing from code driven to doc driven. For each feature you want to add, have LLM do research in the codebase and solution space and ask for a plan, then you have another agent code it out. You still need to understand what’s happening under the hood to make sure it’s not trying to end humanity. A very helpful way to do that is to have LLM create an ascii chart representing how the components work together, or sequence diagrams of how the threads are working at the end of each coding session. If it’s complex also have another vendor’s agent check it. Our current practice is to create a doc that has both ascii charts for human readability and file paths, function names in the descriptive paragraphs for LLM grepability. There is a trend of preparing data for LLM other than for human, not confusing them is one of the hard tasks.

I also imagine there will be tools that help you visualize & plan in the codebase in a more interactive and dynamic way in the near future (for high-level planning, building), more suited for LLM-driven (doc-based, abstracted) engineering.

Biggest blockers aren’t code anymore

In the past month, the biggest blockers in product development usually aren’t technical, but approval bottlenecks. To login with an 2FA-enabled enterprise accounts might take minutes to hours, getting verified on the Weixin Open Platform involved almost a week of back-and-forth, and clearing App Store Connect required four review cycles, adding nearly another week of delay.

Git is still very important.

Know your git commands, esp. when you git pull origin main, otherwise you’ll ended up introducing +10,000 -9,876 lines of code changes to your feature branch haha (when not rebasing well).

Yes, junior software engineer is not a thing anymore.

Building is learning by doing, accumulating early work, that will compound over time. It also signals skills, passion, agency, finishing things, creativity, intentionality, ownership. With great work, there also comes great network. If you are creative, and you know what to build that can create impact, then the opportunity cost of not building has never been higher.

The corollary of the previous conclusion is that, the opportunity cost of not learning has never been higher. With AI, you can learn anything (probably not Quantum Chromodynamics yet, at least not with o1, as a Princeton PhD friend told me before). Knowledge in certain fields has so much leverage. For one, concepts in software engineering is one of them. AI scaled the expertise of coding, so people can focus on finding and describing what they want. But the ability to describe what you want in the terms of engineering is a new skill that needs to be learnt. And this new fundamental skill, to me, seems a lot easier than learning how certain solutions is implemented. With the language of engineering, you can then command your fleet of AI agents to build for you, and you can build a lot more efficiently, which goes back to item number one.

• Principle #1: Learning: Breadth first, depth on demand.
• Principle #2: When AI commoditizes execution, conceptual leverage becomes 10x more valuable.

Finally, to source opportunities, I must (1) draw samples from the distribution of opportunities and (2) attract opportunities. When you ask for opportunities, most of the people will probably say no, but there are always chances that someone is willing to give you a chance. So if you ask enough people, you will get a chance.

To attract, you have to be seen. In 2025 this means you need to have an online presence via a personal website, an social media account that has your record of thoughts or work. More thoughts on this later.

I just wanted to say that, as someone who just graduated and doesn’t have a golden handcuff, I am very excited about the future!

To get a sense of why I am excited, here are some good reads:

• Reflections on OpenAI by Calvin French-Owen
• Searching for outliers by Ben Kuhn
• Software Is Changing (Again) by Andrej Karpathy

I desire to do great work.

• I want to do great work one day, even if this means constant failure, back-tracking and sacrifices.
• I am motivated by curiosity, delight, and the desire to do something impressive.
• I believe the secret to effortless discipline is to have a profound passion/curiosity.
• I work to impress myself, but when I want to impress people, I only aim to impress the people whose opinion I care about, those that I respect.
• If I dive into a field, I aim to become the best, because it simplifies things.
• My success is defined by excellent work in areas that are important to me. I define myself by my strengths instead of weaknesses.

Time and Energy Management

• Life is too short for bullshit, I shall relentlessly prune bullshit.
• I believe anything worth doing is worth doing well, so I invest time and energy in better writing, presenting, communicating, clear thinking, learning, finding the right tool etc.
• To get through the initial energy threshold of per-day work, I trick myself and prioritize tasks in a way that generates momentum.
• I try to avoid thoughts about money and disputes because they are engaging in the wrong way.

Thinking, Planning and Agency

• In college, I treat the education I receive as my own project, that my professors are working for my work and my goal.
• Planning only works for achievements you can describe in advance. 
• I understand that I can bend the world with the sheer power of will with a surprising percentage of time.
• It doesn’t matter how fast I move if it’s in a worthless direction.
• The right goal is to allocate my year optimally, not my day.
• My next twenty years are unknowable because they depends on my next five years. My next five years are unknowable because they depends on my next year. My next year is unknowable because it depends on my next two months. I have the next two months under control, make the best of it.
• I start with first principles, iterate with data, and lean on conviction when data falls short.

Risk, Luck, Success, Failures and Growth.

• My biggest advantage is time and higher tolerance for failure. Therefore I invest my resources for high expected return instead of certainty.
• I understand that every time I make the hard, correct decision, I become more courageous and hard things become easier.
• I ask people I respect for feedback to learn from failure.
• Competition ≠ validation. Individual success is a positive-sum game. Help people at similar stages.
• A decision that I can afford to lose 1x but to win 100x is worth-making. A decision that could end me but win 10,000x is not worth making.
• I compound myself by moving towards options that allow maximize growth and work hard. I understand that exponential curve starts flat at first.
• I have confidence in taking risks. I justify self-belief with self-aware by working hard to learn about my capabilities.

People

• Given that work stamina seems to be one of the biggest predictors of long-term success. I work with people I like and problems I am very interested in to avoid burn-out.
• I try to take care of the people that work with me, and be overly generous with sharing the upside.
• I understand that task conflicts are distinct from interpersonal conflict.
• Be a force of nature.

Law of Attraction / Online Presence

• To attract the right people in the long term, I will post sincerely with substance, assuming my audience are intelligent.

風險

• 基本原則：只嘗試承擔那些你能承受失敗後果的風險
• 為了平衡你的自信與自我認知，你在職涯早期應該積極努力地工作，以了解自己的能力邊界。
• 你應該藉由不斷累積從「我可以做到」轉化為「我已經做到」的實際經驗，來儘早建立自信。
• 選擇風險——你只需要成功一次（就足以解決現階段的問題，踏入下一個階段）。
• 尋找一些小賭注，失敗時損失為 1 倍，但成功時回報為 100 倍。然後再朝成功的方向押下更大的賭注。
• 「反脆弱 (Anti-fragile)」形容的是一種能從波動 (volatility) 中獲益的系統或策略。對反脆弱系統而言，衝擊強度越大，其帶來的益處（或減少的損害）就越多，直到某個臨界點為止。例如，舉一次 100 磅重的啞鈴，比舉 100 次 1 磅的啞鈴更有益。
• 聰明、積極、有韌性的人是反脆弱的。
• 我願意花上足夠多的時間去尋找下一件值得投入的事。但我希望每個專案若成功，都能使我的職涯中其他成就看起來只是註腳。
• 要有信心做有風險的事。成功意味著做一系列有風險、經過評估的事情。
• 面對有風險的事，人不可能總是做出正確的選擇——你必須嘗試足夠多的事情，並隨著你所獲得的新資訊迅速調整。
• 感受與理解風險：從風險小的事情開始嘗試，逐步去做擁有更大風險的事情。你很快就會發現有風險的事的負面影響遠比你想像的小，而正面效益則遠比你想像的大。
• 缺乏經驗會讓你害怕有風險的事情，但實際上，你越年輕時越有能力去承受更多風險（「更多」＝想要多少有多少）。
• 「大部分人對風險的看法是錯誤的——例如，繼續待在大學看似是一條零風險的道路。然而，在你最具生產力的四年什麼事都沒做，其實是非常危險的。」— Sam Altman
• 關於未來，沒有絕對正確的道路，但你應該去做那些最可能讓你走上卓越道路的事情。
• 大多數情況下，「零風險」的道路已經被定價，預期回報也因此受限（比方說，你的薪水就是一種定價）。走這條路註定無法獲得高於其道路平均的回報 (linear vs superlinear)。
• 記住你終將一死，因此沒有理由不去冒大的風險，試著在宇宙中留下自己的痕跡。
• 「提醒自己即將死去，是我遇過最能幫助我做出人生重大決定的工具。因為幾乎所有事情——外界的期待、驕傲、對尷尬或失敗的恐懼——這些在死亡面前全都不重要了，只留下真正重要的事。記住你終將一死，是我所知道避免陷入『以為自己有所失』陷阱的最好方法。你已經一無所有了，沒理由不去追隨你的內心。」— Steve Jobs，2005年6月12日史丹佛畢業典禮演講

心理上如何面對不確定性

• 當你試圖跳出一個局部極大值（例如零風險的道路）時，你的第一步肯定會是下降。
• 學會與不確定性共處。一個訓練容忍的小技巧是每天早晨沖冷水澡，你會經歷三個階段：「幹幹幹」，然後你就會適應，並繼續想其他的想法。
• 恐懼驅動的決策幾乎總是糟糕的。你應該試著辨識自己的情緒並且處理它們（把情緒化的想法和 ChatGPT 闡述，對發掘潛在的焦慮原因非常有幫助）。
• 除了自我認知和合理的自信之外，來自宏觀層面的樂觀和信念在面對不確定性時非常有用。
• 小心「努力迷思」：「事情沒有效果是因為我還不夠努力」→ 這是「瘋狂」的定義

Risks

• Ground rule: Only risks that you can afford to fail are worth taking
• To balance your self-belief with self-awareness, you should work hard in your early career to educate yourself on your own capabilities in order to Cultivate self-belief early, by getting more "i can do it"→ "i did it" data points.
• Thinking about risk the right way, you only have to be right once (to make it to the next level of whatever you are progressing).
• Look for small bets you can make where you lose 1x if you're wrong but make 100x if it works. Then make a bigger bet in that direction.
• Anti-fragile describes systems or strategies that will benefit from volatility. For the anti-fragile, shocks bring more benefits (or less harm) as their intensity increases, up to a point. e.g. lifting a 100 lb weight once is more beneficial than lifting a 1 lb weight 100 times.
• Smart, driven, resilient people are the anti-fragile.
• I am willing to take as much time as needed between projects to find my next thing. But I always want it to be a project that, if successful, will make the rest of my career look like a footnote.
• Have confidence in taking risks. Success means a series of well-calculated risks that one took to go from nowhere to somewhere.
• It's impossible to be right all the time—you have to try many things and adapt quickly as you learn more.
• Start with small risks, then you should take bigger risks. You will soon learn that the downside of risk is much smaller than you think, and the upside is much bigger.
• Inexperience makes you fear risk, but it's when you are young that you can afford the most (most = as much as you want).
• "Most people think about risk the wrong way—for example, staying in college seems like a non-risky path. However, getting nothing done for four of your most productive years is actually pretty risky." — Sam Altman
• Regarding future, there is no right path, but you want to do the things that is most likely to get you on a path to do something great.
• Most of the time the no-risk path is priced-out. The expected return is limited (e.g. priced as your salary), you can never get above average return following this path.
• Remember that you are going to die, there is no reason why you shouldn't take big bets to try leaving dents in the universe.
• "Remembering that I'll be dead soon is the most important tool I've ever encountered to help me make the big choices in life. Because almost everything — all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart." — Steve Jobs, June 12th 2005 Stanford commencement speech

Dealing with uncertainty mentally

• When you are popping out of a local maxima (the no-risk path), your first step is definitely a drop.
• Be comfortable about living with uncertainty. One trick to build tolerance is to cold shower in the morning, where you will go through three stages: fuck, fuck, fuck and then you will be comfortable enough to think clearly.
• Decisions you made when you are in panic is almost always bad. You should always try to recognize your feelings and deal with it (verbalizing every thought with ChatGPT could be very helpful at pinpointing hidden worries).
• Besides self-awareness justified self-belief, optimism and faith from the macro could be very helpful when you are living with uncertainty.
• Beware of the effort myth so you don't get stuck: "It's not working because it's I'm not working hard enough" → definition of maniac 

好的點子是人們願意付錢的點子；好的行動是能採集或驗證用戶真實想法、畫像與行為的行動

如果有用戶為某問題所困，迫切需要解決方案時，那他們會願意付錢嘗試你的解決方案，也會為你提供最多有用的洞見，以便你優化解決方案。這些用戶是你需要透過「訪談」發現的用戶，而這些點子就是好的點子。

為了了解市場對產品的真實反應，我需要採取行動，比如發佈產品、向用戶展示使用方式、追蹤與分析行為數據、與用戶溝通等。如果我發佈了一個產品，但沒有辦法追蹤用戶行為並聯繫到用戶，那我就無法了解市場是否真的想要這個產品，那這次發佈就等於是在浪費時間。

在開始打造解決方案前，一定要分析問題的強度、頻率以及既有解決方案

應用層面產品的點子很多，但真實存在的痛點問題比較少。在開始打造解決方案前，一定要分析問題的強度、頻率以及既有解決方案，進而思考自己的產品能提供目標客群多少價值。如果沒有想清楚，不要貿然行動，否則便是在浪費時間。

一個浪費時間的例子：我有一次因為一時想不到足夠好的點子，便說服自己開始打造某個工具，美其名「這個工具可以解決自己的問題」，而實際上這是在躲避對專案沒有進度的 panic move。此時應該靜下心，捫心自問想做這個點子是因為它真的能解決問題，還是因為自己受到情緒作用而決定推進。

用產品調研市場的瓶頸是獲得用戶反饋，因此要專注在優化獲得高品質反饋的過程

問一個朋友並獲得答案最短只要 3 秒；線上預約一個朋友訪談最短需要 3 分鐘；透過郵件來協調用戶訪談最短要 1 天；打造一個能給用戶測試的產品最短只要 17 分鐘（包含數據追蹤系統、登入系統、付費系統可能要額外一天，但這是因為我還不是非常熟悉操作方式）；找用戶從測試開始到下階段性結論大約最短要 3 天；

一個解決方案是手動 onboard 所有用戶：讓對產品感興趣的用戶加入 waitlist，直到你聯繫並手動 onboard 他們。這個過程可以篩選掉那些看到覺得很酷想玩玩的非目標用戶。中間可以加 paywall 進一步篩選那些「並不是迫切需要」的用戶。

重新思考「拖延」

拖延是人類畏難的自動保護機制，但現在即使是我們沒有做過的事情、想來覺得很困難的事情，在 AI 的輔助之下「其實可以很簡單」。比方說，半個月前，我想在其中一個產品加入登入驗證系統，但因為我覺得它很複雜很難，所以我拖到了隔天，結果隔天發現用 AI 工具 15 秒就能解決。

那有什麼事情是值得拖延的呢？大量資源運用的決策，比方說「接下來 3 天要打造什麼產品，為什麼？」

提供流量之神眷顧的機會，同時可以感受有多少人可以與你所解決的問題共鳴

找用戶測試的目的是獲得關於用戶的真實資訊；而獲得用戶真實資訊效率最高的方法是用戶訪談（視訊 > 電話 > 社交軟體 >> Reddit chat >> 郵箱）。但也不妨直接在公開的社群媒體上發表產品，原因是因為發佈一篇貼文的時間成本很低，也可以在零碎的時間運營留言區，好處是可以透過貼文轉發次數很直觀的感受有多少人與這個問題共鳴。此外，如果你有在使用前收集郵箱，那麼高流量也可以增加早期產品的觸及目標用戶的數量。

只要所花時間不那麼多的話，社交媒體是一個可以利用的黑天鵝。

相信自己，穩步前進