程序員最大的本事，問他本人多半答不到點子上：不是哪門語言，不是哪個框架，是調試練出來的那套肌肉記憶。這套動作有個隱藏前提——世界是可以 debug 的。
第一道工序就決定大半勝負：把問題定義出來。“網站太慢"不是問題，是情緒。“移動端首屏超過 3 秒，轉化率掉了兩成"才是問題。定義模糊，後面每一步都打在空氣裡。程序員不信"我覺得"“差不多"“大概是這個意思”。輸入是什麼、輸出是什麼、什麼狀態算解決——三件事問清，問題解決了一半。
第二道，拆。面對大麻煩，本能反應不該是"怎麼解決它”，而是"它能拆成哪幾個互不干擾的小問題”，拆到每一個都簡單到不用想就能做為止。寫一本書，拆到章節，拆到段落；找一份工作，拆到簡歷、投遞、筆試、面試、談薪。大問題嚇人，多半只是沒拆。
第三道，假設加驗證。東西不工作了，外行的做法是亂改，改到能跑為止；專業的做法是：收集現象，提出最可能的原因，設計一個最小實驗去推翻它，推翻就換下一個假設。一次能證偽的小實驗，頂十次"再試一次”。之前另一篇拆 Docker 連鎖故障的文章裡就是這個路數：報錯在 A，根因在 B，B 修好，A 自己消失。
第四道，先找現成答案。遇到的麻煩，九成九別人遇到過，且有成熟解法。第一反應應該是"誰解決過這個問題"，而不是"我從頭做一個"。拿設計模式和開源庫解題不是偷懶，是對成本負責——重複發明輪子，發明出來的往往還是方的。
第五道，先跑通最小版本。完美是個移動靶，先出一版讓現實打分，再改。紙面上改十輪，不如落地跑一輪。
第六道，假設最壞會發生。設計的時候就要問：輸入是髒的怎麼辦，網絡斷了怎麼辦，機器掛了怎麼辦。失敗要早，失敗要響——問題暴露得越早越便宜，默默吞掉錯誤是最貴的那一種。
最後一道才輪到自動化：流程沒跑對之前，別急著上腳本。手工重複不是勤勞，是不肯投資自己——但前提是流程本身已經對了。給錯誤的流程做自動化，只是讓錯誤提速複製。
反方也得接得住。這套流程這麼死板，做事反而更慢？——慢是賬面：花一小時做計劃，買回的是十小時收拾爛攤子，這筆賬誰都會算，誰都不肯先付。現實世界沒有日誌和單元測試，這套有什麼用？——現實世界有驗收標準。不敢寫下"什麼算解決了"，那不是生活，是無頭蒼蠅換了一種説法。
不適用區也劃清楚：這套是給事用的，不是給人用的。情緒優先的問題，先聽，別拆；把人當系統裡的根因去 debug，兩頭都輸。世界可以 debug 的前提，是你敢先把問題説準。很多人的毛病從來不是不會修 bug，是不肯承認 bug 在哪。
