六年前很想開的一門課，叫邏輯思考，希望能教會沒有程式背景的人，不論是藝術家或是設計師，希望他們能夠透過對程式的學習，將資訊技術應用到自己的領域去，這也是我一直以來追求的目標，雖然到現在還是沒有什麼具體的成果，但是這幾年的實戰下來，其實也累積了不少心得。
總結來說，程式還是令人畏懼的，所以我很想要找出為什麼害怕，也因為這樣我對非常多的同學做了心理輔導，也跟他們當好朋友聊心事，我想知道，他們到底怕什麼。
雖然我很想把這些東西發展成論文，但是目前還是散寫一番就好，嚴謹的研究留著之後拿來申請計劃用好了XD
大抵來說，程式入門的幾個心理跟生理門檻需要跨過的有
1. 怕犯錯而且回饋來得慢
初學者很害怕犯錯，他們很怕寫錯東西，即使我不斷在強調寫錯程式不會害電腦永遠開不了機（雖然這句有點是騙人的，沒寫好真的會永遠開不了機，比方說寫了一個開機自動執行的關機程式，那頭就大了....），不會害死電腦這樣的心理建設雖然有點成效，但是我看得出來，面對一片空白的背景，他們是動彈不得的，因為撰寫程式的過程，大概要經過十分鐘後，程式碼累積到一個程度可以嘗試執行才會知道自己寫的是對還是錯，而這十分鐘，是一片的混沌與黑暗，對於沒有辦法在腦中裡建立程式架構的心智模型的人而言，這是一種漫長的煎熬。
畫畫或寫作也相同，如果不是腦海中有東西，面對一張空白畫布或稿紙也常有無從下手的煩惱，但相對於寫程式而言，畫畫或寫作的心理負擔相對更小，進入到執行面的機會更大，因為畫畫下個幾筆就知道對不對，寫作寫完一句話就能感覺順不順，因為這兩個活動的回饋來得快得多。
解決的方式有兩種，從教育方面，我都先教同學寫出架構，例如先寫出許多的空白函式，然後再寫裡面的細節，而不要一行一行寫下去，因為程式要一直等到架構完整才能執行看看對不對，先大樣再細部。傳統的資訊教科書教完指令就從main()開始，然後一行一行的指令寫下去到hello world秀在螢幕上，教學上雖然看似簡單，實務上會造成回饋太慢。
快速的回饋反應可以讓他們比較敢動手，第一步總是困難的，別讓他們等太久是很重要的。
2. 語法不熟所以不知道自己在寫啥
程式本身就是另一種的語言，當我們對這個語言不熟的時候，恐懼是會伴隨而來的，就像同學如果對自己的英文沒自信，那麼遇到外國人問路，大概就會閃閃躲躲很害怕。而要摒除這樣的恐懼，最簡單的方式，就是「拆」，當他們發現，聽似聽不懂的一句話，拆成一個一個單字後其實每個字都懂，他們只是需要慢慢來，不要一次丟過來，那麼就不會怕了，所以在教學上不能只教程式，而必須搭配每個指令與步驟造成的變化，聽過我上課的同學就知道，我一個重複20次的迴圈，我就真的會重複20次，然後把每一次裡面所有的變化都講清楚，讓大家知道雖然是一個複雜的東西，背後的運作卻是簡單的。另一種方式則可以透過新的介面，讓每一行程式碼都伴隨著視覺上的架構圖同時建立，例如他們每宣告一個變數，視覺方面就讓他知道有多一個東西在等著使用。
3. 除錯除不到錯哪也不知道
任何專業的程式設計師都知道，除錯訊息有多重要；然而所有的初學者都不知道，錯誤的訊息在哪裡，就算他們看到了也看不懂，即便是標榜最平易近人的processing，除錯訊息還是上帝的語言。因為不知道錯在哪，所以一旦嘗試執行了幾次，他們就會放棄，因為錯在哪裡都不知道的無力感，會不斷澆熄學習的熱情。這點也是我認為目前為止最大的關卡，因為寫程式一定會犯錯，即使跨過了第一關不怕犯錯，但是卻沒有人能夠正確指出他們到底錯在哪（就算指了也看不懂啦）。教學時老師會幫忙看錯誤訊息，但是做作業的時候怎麼辦？自己創作的時候怎麼辦？即使回家後滿腔的複習熱情，也會在被一連串的ERROR打槍後決定改玩英雄聯盟去。我們沒辦法在教學時告訴他們所有可能的錯誤狀況，只能教他們在錯誤發生的時候知道怎麼看錯誤訊息，我認為關鍵在於工具，而這點在目前所有的程式工具都做得非常不理想。理想上，除錯的視覺化是一個很重要的環節，將程式的資料流視覺化或許是個可能的方向，至少讓他們看得出來自己設立的資料是怎麼被處理及如何產生變化的，這也會是未來要持續努力的目標吧。
4. 範本人人愛用久離不開
大家都愛範本，拿範本改來改去是最容易的，這點在近期的程式工具發展就看得出來，都會提供各式各樣的範本，有的會把架構架好，有的甚至會寫好一些資料流處理的程式碼讓人去修改了，各種範本的教學也應該重視，讓同學容易獲得成就感，延續熱情。然而要很小心的是，範本實際上是一種速食毒品，上癮了之後難脫離也走不出自己的路，一旦養成習慣，當他們想要自行修改卻發現怎麼寫都錯的時候，挫折感會比從頭開始還要更重，所以範本的教學必須適可而止，讓他們可以簡單完成一些小型程式嚐嚐甜頭，但是課程比重絕對不能太多。
5. 別想太多當佈置而不是建房子
資訊背景的教學，會教會學生如何有效率而且正確地思考，並在腦中建構邏輯模型，撰寫程式不過就是將這些邏輯編碼出來而已，所以我們常常有個錯覺就是邏輯模型建立後就覺得程式已經寫完了，某個程度上來說也不算是種錯誤啦。而習慣以視覺思考的設計師或藝術家，這樣的運作方式其實是會造成困擾的，一來是他們本來就不習慣建立這種有組織的架構，二來是他們習慣看動看，即便腦中先有了印象，動手了之後還是會不斷地依據視覺的回饋做修改，所以過於強調思考的方式，對他們來講是不對盤而且問號滿滿的，而且一旦在思考中卡關，他們就不想這麼做了。因此在教學時，我總是要他們先寫一個小功能，看一下結果後再慢慢擴充，可能這邊加一條，再看看後就那邊又加一行，像是在做裝飾的心態，而不是照計畫行事。在工具上，快速的視覺回饋當然是個重點，而輕鬆的介面是另一個會影響心態的關鍵，這點其實我覺得scratch做得很不錯，但是這樣的設計介面也會讓大家覺得做不出正經作品的感覺。輕鬆易上手跟專業重質感如何並存，也會是設計工具發展的一個很重要的特色。
中間其實很想穿插對於許多程式工具的評論與分析，例如從processing、UDK、Unity、VB到VS等，不過實在太冗長我懶得寫了，留著之後寫計畫用吧～
簡易的架構方式、快速的回饋機制、理想的除錯介面、豐富的範本、輕鬆做裝飾的心態，從教學及工具兩方面的發展，或許能夠盡量達成我設定的目標吧，隨著教學經驗跟白老鼠數量的累積，我相信我能夠更趨近自己的理想，目前的這些想法，我不認為是100%正確的，這些只是一種暫時的心得，同樣隨著時間的增長，其中或多或少也會有所變化吧，這也是自己要不斷修正的部份，一輩子的志業，不是嗎？
