打個比方，這就像心中有一些關於音樂的設想，那麼你需要學習如何演奏才能把它表達出來。當然，其中的學習過程絕對會嚇退一幫專業音樂人。可是，如果你害怕出醜害怕被罵，擔心這個擔心那個，那麼我敢肯定，成功將永遠不會眷顧於你。畢竟，沒有哪個樂隊是不具備任何音樂知識就隨隨便便一不小心就能成功的。
遙想當年，我早在高中開設“Intro to BASIC”課時就已經會程式設計了。我依然記得其中有一個挑戰是隻能使用Apple II的16色和低解析度模式來做一個視覺演示。我很快就想出一些演算法，使得程式能在螢幕座標上迴圈畫線，並且改變線的顏色。這大約才花了我半個小時的時間來程式設計和除錯程式碼，完工的時候甚至還有點沾沾自喜。
但是，我嚴重低估了大家的創造力。
我還深深的記得，其中有個人演示的全是動畫和陰影圖片。說他牛B是因為他的作品讓人驚呼奇蹟，比如有血珠從一個頭蓋骨的眼窩裡流出來滴進螢幕下方逐漸升高的池子裡。而這僅僅只是他演示中的一個片段而已。從這件事情上，我認識到我沒有我想象的那麼厲害。
經過軟磨硬泡，我終於看到了他的程式碼。哇塞！用來變色和畫點與線的指令就有成千上萬條。其中甚至是沒有迴圈，也沒有變數的。而為了使血珠有動畫效果，他先是畫了一個紅色像點，過會兒再在這個下面畫第二個，以此類推。所有座標都是硬編碼。想知道他是如何掌控這些畫的東西嗎？他把他做的東西統統更新在了一張方格紙上。
不得不說，在這件事上我犯了個固步自封的錯誤，沉浸在以前的經驗裡，不思進取，不去創新。然後，我在想這個程式的程式碼可以如何優化以顯得簡潔明瞭。當然，那個製作了頭蓋骨的傢伙才不考慮這些呢，他並不在乎這個程式是否繁冗也不需要去維護。他想要的只是一個能展示他想法的方式。
這裡還有另外一個教訓容易被忽略。那就是，如果你想要同時關注使用者的最終體驗和提供這種體驗的程式體系結構，這是相當相當困難的。甚至也許是不可能的任務。我認為解決這個矛盾的唯一方法就是忽視後者。直接去寫程式碼，就好像你剛剛才學習程式設計那樣，避免用原有的經驗去禁錮自己的思維模式——如果你想成為一個真正的軟體工程師，而不是一個有經驗的設計師。