有時老師並會不理解學生遇到的困難

前幾天聽說有「大老闆」4.2萬台幣要找到會，1.硬體設計，2. 系統整合，3. 系統軟體設計，這樣子的工程師。不知道這位老闆到底有沒有概念這樣子的工程師要花多少時間才可以訓練出來？而現在到底有多少學生願意投入這樣子的課程被訓練呢？

很久沒寫code了，最近因為要比較積極寫以後開課用的教材，需要藉此找回一點手感與想法。之後的機器學習課程也是要以遊戲與競賽來設計，其中一個目的也為了讓同學理解在自己開發的並不是很完備的模擬器裡面與實體上到底有多大的差異。

我過一陣子也會找學生來幫我試試看python轉C在7697上是否可以運作，要不然只好在PC上做比較複雜的計算之後再傳命令過去了，希望延遲不會太離譜。

有時老師並會不理解學生遇到的困難，於是直接跟學生說，「啊！就這個演算法放進去就好了啊！」但是這也是在老師的腦子裡模擬的而已，遇到真實的狀況，真的很不一樣。我這次自走車拿到的材料就是一堆地雷，即使超音波感測器這種算是故障率不高的元件，問題在於，我手上這顆，很奇特的，在短距離忽然變成長距離時，數值會從0cm到200cm間劇烈跳動 ，需要幾個ms間多讀取幾次才會趨於穩定。遇到需要轉彎處，每次行為都不太固定，此時一般的演算法根本派不上用場。需要的是自己去實測一下這個超音波的特性才會有對策。

偏偏在把對策轉成code時，不可能一次就成功，那時候，真的不知道是自己寫錯code，還是方法錯了，錯的次數久了，都開始對自己的想法感到懷疑了，老師如此，學生就更不必談了。我這兩天就是遇到如此狀況。我寫的程式只不過不小心讓更新資料用的迴圈少做了一次，就有時可以，有時不行。這個bug我從昨天到今天共花了五個小時才找到，最後只不過是把「>1」改成「>0」就可以了。重覆的測試大概花了幾十次。蹲下又站起來幾十次，實在辛苦。

有人會說，這麼小兒科的應用為什麼要花這麼多時間？事實上，系統與軟硬體整合面對的都是這種虛擬與真實之間交替產生的錯誤，程式碼一點也不複雜，演算法也可以很簡單，但是能夠面對不可預知甚至是隨機出現的錯誤，還可以找到辦法解決，才是這種工程師的價值所在。

我們不可能一開始就能解決很大的問題，因此從遊戲與小系統入手很剛好。而功力就是在一次又一次的試誤中累積起來的，耐力與毅力也是。

所以這樣子的課程每週要花比其他課程更多時間，看起來又好像學不到什麼，要是分數給得不夠甜，難怪學生會不願意來上。

因為太久沒寫code，連我這種算有一點經驗的，為了找回手感都要花這麼多時間，何況是沒有先備知識的新手？

奉勸國家與大老闆要務實一點，這些東西沒辦法發論文，卻是一切科技業的基礎。沒有年復一年培育出有這類基礎能力的新血，說科技業以後要多發達都是騙人的。