為期八個月（六個月學習加兩個月找工作）的程式導師實驗計畫第三期在今天正式告一個段落。依照慣例，這一篇要來分享第三期的成果，還有未來改進的方向跟後續。

首先呢，針對第二期的改進之前已經寫過一篇分享（從線上到線下：第三期教學實驗滿月心得分享），這邊就不再多說了。

接下來直接從第三期的成果開始好了。

第三期成果

剛開始的時候一共有 62 個學生，到計畫結束的時候剩下 45 人，淘汰率大約為 27%。有些是被淘汰制淘汰的（兩週內每日心得累積缺交三次或是連續兩週未交作業），另外一些則是主動退出，原因有許多種，例如說跑去唸資工所、發現自己對工程師沒興趣或者是因病沒辦法繼續跟課等等。

45 人裡面有 6 人是工程師加強班，所以不列入最後求職的數據裡面。因此，會列入統計數據的學生一共有 39 人，底下是這些人的進度分佈：

2124 週：18 人（9 人找到工作）
1620 週：8 人（2 人找到工作）
1115 週：6 人（3 人找到工作）
0610 週：7 人

因此，總共有 14 人找到工作，轉職成功率約為 35%。

底下是薪水分佈的區間，含下不含上
例如說 30k~40k 就是 30k 以上未滿 40k：

30k40k：3 人
40k45k：4 人
45k~50k：5 人
50k 以上：2 人

可以發現高低差距滿明顯的，這跟上面的進度分佈有一點關係。這一期有個很特殊的狀況就是有些學生在比較早期的時候就找到了工作，那時的進度可能才在第十週左右，只會最最最基本的 HTML、CSS 跟 JavaScript，而公司認為可以訓練培養，所以薪水會拿得比較低一點。

以他們那時候的程度來說我覺得是合理的，也跟他們說記得滿三個月或一陣子之後跟主管要求調薪，能力上升了薪水自然要跟著調高。

而 50k 以上的人原本就已經有程式相關經驗，有的甚至已經有相關工作經驗，只是來我這邊把基礎再重新修煉一遍而已。

這 14 人的薪水中位數為 43.5k，平均數為 44k。

原本其實我預計轉職成功人數可以更多，進度在最前面的那 18 人其實都有機會，最後只有一半 9 人在計畫截止前找到工作。

剩下那 9 人有 2 人沒有求職意願，4 人正在求職，3 人狀況不明。

以上就是第三期關於轉職的成果報告，底下則是一些其他的產出。

與學生合作專案

不知道大家有沒有看過一些玩遊戲學程式的網站？例如說 Flexbox Froggy 或是六角學院的 Flex Private，都是藉由有趣的小遊戲來學習特定概念。

這一期的課程我也做了兩個，第一個是：Lidemy HTTP Challenge，目的是想讓學生熟悉 HTTP 的相關操作以及概念，是純文字的，所以就算是用 curl 也可以順利遊玩。

第二個是異世界?r3:0 挑戰，是跟學生 Min 合作的作品，關卡的 idea 主要是我出的，其他都交給學生來處理，最後做出了一個 MUD 風格的遊戲，裡面的題目都與網站前後端有關。

再來不太算遊戲，是 Lazy Hackathon，是與另外一名學生 Yakim Hsu 合作的作品，我也只是大概提供了 idea，其餘實作皆由學生自行完成。就是故意做一個速度很慢的網站，讓大家想辦法去優化。

這一期出了以上三個我覺得滿好玩的專案，希望以後也能有更多類似的產出。

課程筆記與心得

這一期強烈建議大家做筆記，還建了一個 hackmd 整理同學們記下來的筆記，加起來有一百多篇，內容都與課程所教的技術有關，然後課綱本來就滿廣的，所以他們記下來的筆記內容也很多元，有學到類似主題的朋友們可以參考看看。

除此之外，也寫出了一些不錯的文章，並不一定跟技術有關，底下稍微舉幾篇當作範例：

  1. 轉職網頁工程師最初的一段路  — — Lidemy 程式導師實驗計畫心得 by cian
  2. 記在程式導師計劃之後（下）：求職天堂路 by minw
  3. 淺談：我的前端學習之路 by ClayGao
  4. [資訊安全] 密碼存明碼，怎麼不直接去裸奔算了？淺談 Hash , 用雜湊保護密碼 by CodingCoke
  5. 前端中階作業：event loop、Scope、hoisting、closure by hugh
  6. [第二十一週] React 環境建置：手把手步驟 & 超級懶人包 by yakim

課程雖然結束了，但這些筆記與文章會留下，等到哪天再次碰到以前曾經解過的問題，卻忘記當初怎麼解，這些筆記就是最好的解答，看一下就可以喚回記憶。

反思

接著是這一期教完的一些反思，跟上一期比起來，會在意更「底層」的問題。

想要教出什麼樣的學生？

在計畫一開始的時候，我就把目標說得很明確了：

希望能在結業時培養出合格的（意思就是找得到工作）的工程師，並且在就職後依舊能持續成長，成為好的工程師。

而計劃的收費方式也是根據「成功求職」而定，因此可以認為這一堂課的目標就是要教出找得到工作的學生。當初會這樣定是因為我覺得這是個不錯的標準，能找得到工作就代表有一定的實力。

但從這一期的狀況看來，我覺得「求職」這個標準不管用了，因為現在的求職門檻比我想像中的還要低。似乎因為職缺太多的關係，門檻也跟著變低了。儘管最近幾年轉職的人很多，但我覺得門檻沒有跟著提高，對於新手工程師似乎還是供不應求。

那如果不以求職為標準，要用什麼為標準呢？例如說想培養出「基礎紮實」的工程師？

怎樣才叫做「基礎紮實」？

我後來發現在我的定義裡面，基礎紮實這件事情其實很難達成，難的點就在於它是一個很容易被攻破的東西。假設今天我認為的基礎有 100 個這麼多，只要缺了一個，我就沒辦法覺得這個人基礎紮實。

舉個例子好了，假設有一個人關於 this、closure、event loop、prototype 這些經典的 JavaScript 問題都回答得很好，結果我問他：「變數跟常數的區別是什麼」，他卻回答不出來；或者是他居然不知道二維陣列是什麼，儘管會的很多，但還是會因為他不知道這些「我認為的基礎」，沒辦法把他當作是個基礎紮實的人。

所以對我來說這不是算分數，不是 100 個裡面會了 99 個就可以，而是要 100 個全部都會，只要少了任何一個都不行。

但這樣子的判定方式會碰到的難題是，在教學的時候只要漏掉任何一個基礎沒有教，教出來的學生就會被我自己認為基礎不紮實。

再來還有一個問題，讓我反思自己的課程是不是太著重在工具層面上。我原本就有特別小心這一塊，當初在設計課綱時我的目標是必須要讓學生知道工具的原理以及使用，才不會只學到表象，才能不役於物。

但實際情況是雖然那些工具的原理以及使用學生們都懂了，但對於一些我認為是基礎的問題卻沒辦法解出來，或者可以解出來，但解的方法很不「直觀」。

直接舉一題實際的例子，HackerRank 上面的一個題目叫做：Sock Merchant，給你一個陣列像是 [1, 2, 2, 4, 5, 2, 4]，每一個數字代表一個編號的襪子，問你總共有幾雙襪子。

以上面的陣列來說，答案是兩雙（2, 4 各一雙）。這一題對我來說非常直觀，給了一個 O(n) 的解法（但會用到額外空間）。可是對有些同學來說，他們的「直觀」是 O(n²) 的解法，而且想不到 O(n) 解。

上面這個例子其實有討論空間，不過這只是其中一個案例而已，我可以舉出更多更多更基本的題目，例如說找質數、判斷質數或者是印出聖誕樹等等，這些題目就又更基本了，但卻依然有些學生沒辦法解出來。

我認為這樣子的成果在教學上，是有點本末倒置的。因為這代表在工作上實作商業邏輯時，很有可能會繞了一圈來實作，導致程式碼變得很複雜，我覺得這是比「不會用工具」還更嚴重的事情。寫到這邊突然可以理解為什麼有些公司面試的時候要考演算法了。

課程上對於前端的工具使用以及「前端的基礎」我自認教得還行，但我卻忽略了更底層的「程式的基礎」。就像一個金字塔那樣，我教了上層卻忽略了下層，如果本來就有基礎的同學，在我的課程學完前端基礎以後如虎添翼；但若是本來沒基礎而且也沒有特別訓練過，就算學完前端基礎，我也不會認為是個合格的工程師。

這讓我認真思考是不是之後要來嘗試看看新的模式，新的模式幾乎不教工具也不教前端，就一直練習這些「水題」（對工程師來說寫起來像吃飯喝水般簡單的題目），培養程式思維。

除了練習程式解題以外，也會一直寫 code，寫一大堆小工具，例如說可以用 Node.js 寫個簡單的記事本啦，爬蟲啦，chatbot 啦，寫一大堆的專案培養 coding 能力。

結業的時候雖然可能不太懂前後端，也不知道什麼是 React 什麼是 Redux，但至少對寫 code 是有自信的。仔細想了一下，發現這其實就是我自己走來的歷程，先瘋狂地寫 code，寫一大堆小東西出來，先確認自己會寫 code，再來學其他東西。

作業規模過小

第二期就有發現這個問題，但第三期並沒有完全修正過來，雖然有加了「挑戰題」這個東西，但其實改善成效滿有限的。

我出作業的時候是以一個簡單的 MVP 為目的在出的，所以留言板就是可以留言就好，blog 就是可以發文就好，就只要這麼簡單就可以了，但我後來發現這樣是不行的。

我之所以會把規模縮小，是因為我知道完整的專案長怎樣，而原理其實都在這個「縮小版專案」裡面，只要能實作出縮小版，完整的專案就不會太難。

可是對學生而言，他們做小的專案就只知道縮小版長什麼樣子。那些大專案不是因為能力問題而寫不出來，只是不知道怎麼開始，或是不知道怎樣才算是「大」。他們不像我一樣有經驗，所以完全想像不到完整的專案的面貌，這是因為經驗上的落差導致的教學失誤。

比較好的調整方式是加大作業規模，同時也加大我在上課時示範的專案規模。例如說比留言板跟部落格再複雜一點的論壇之類的，或是也可以實作出一個電商網站。總之複雜度必須要比之前高很多，才能讓學生看到一個更完整的專案會長什麼樣子。

「缺點」

如果要找出自己的課程跟其他的最大的不同，我會說是「缺點」。

臉書上很常被推到程式教學相關的廣告，冷門的熱門的我幾乎都看過了，看過他們的網站，看過教學內容，看過學員評價，全部都看了。發現了一個共通點，就是：「看起來好像都很厲害」。

可是只有我覺得這樣很奇怪嗎？

就有種…看起來很不真實的感覺。對外把課程講得多好多好，優點一大堆，可是缺點呢？可是壞的一面呢？總不可能你覺得自己的課程已經完美了吧？

我能理解很多人不會把這一面透露在外，對外的形象一定要是完美無缺的，好像這個課程就是真的 100 分那樣。有些人可能認為把壞的那一面透露在外是不好的，但我不這麼認為。

我想做的就是把課程攤開來，誠實地跟你說我覺得這邊我做得很好，那邊做得很差。我不在乎你看完課程的檢討或是學員的負面心得之後是不是就不想來上這個課程了，我覺得這不是我能也不是我該決定的。我把好的壞的都跟你說了，剩下要不要來是你的選擇。

這是我想做到的。

學生自助餐

這個詞我在隨意談看學生求職心得感想裡面有提到過：

因為如果是這樣的話，很容易就會造成「學生自助餐」，外面表現不好的學生一律切割，說那都是他們的問題；表現好的就通通把功勞攬在自己身上，說這都是自己厲害。

以前在學生時代，相信大家多少都有碰過會依據成績高低而大小眼的老師。成績好的同學做什麼都可以，成績不好的同學做什麼都錯。那時候完全不理解為什麼會有如此的差別待遇，但在教了愈來愈多學生之後，多少可以體會為什麼老師比較喜愛成績好的學生。

第一，成績好的學生會讓老師花比較少時間回答問題，減輕老師的工作量。例如說成績好的能夠問出一個好問題，回答後也一點就通，身為老師就不用花很多時間在他們身上。

第二，成績好的學生會讓老師有種「自己教得真好」的錯覺。會說是錯覺是因為成績不好的學生明明也是自己教出來的，這個錯覺也是學生自助餐的另一種展現。

所以成績優秀的學生既可以幫老師省時間，又可以帶來成就感。

但我沒有說這樣是對的，我只是觀察到了這個現象然後跟大家分享而已，我不認為成績不同的學生就可以差別待遇。回答問題本來就是老師的工作，如果問題問得差，那就教學生怎麼把問題問好。如果教學教得差，那就自己想辦法增進教學能力。

寫出來是為了警剔自己，不要成為這種老師。

如果還有下一期

雖然短期內應該是不會有下一期了（理由下面會講到），但還是可以來整理一下之後可以改進的東西，要開下一期的時候就能快速參考。

第一，如同前面在講基礎那邊所提到的，可以考慮把課程大轉向，不教前後端也不教這些工具了。我想回歸到最原始的狀態，讓學生能學會「寫程式」這件事。

我可能一樣會從 JavaScript 開始教程式基礎，然後開始帶學生寫一些水題，就那種 ACM 一星題之類的，接著可以做一大堆應用類的小作品，例如說寫個爬蟲，寫個五子棋，寫個猜數字之類的，讓學生們覺得自己是可以寫 code 的。

課程時長可能會縮短成三個月，不要以為這樣很長，我覺得這樣搞不好都還不夠。不過如果課程真的轉向有些問題需要解決，第一是如果還是要求學生每週付出 40 小時，還剩多少人有這意願？第二是如果不以求職做為收費標準了，那學費該怎麼算？

如果真的要改做這個，我覺得我應該會想優先做成免費的線上課程吧，但細節還要再想想就是了。

第二，若是沒轉向而是以第三期為基礎加強的話，第一點需要改的是作業以及教學的示範，要做出一個足夠大的專案，常見的例如說論壇跟電商網站，也可以做出像是 Medium、Twitter 之類的東西。

再來是學生寫完作業以後，應該讓他們根據我提供的指南先做第一次自我檢討，檢討完修正完才傳上來。會想這樣改是因為改作業的時候會發現很多學生犯一樣的錯，第三期我就有統整好寫下來，叫他們交完作業可以看。

可是如果交了作業才看，那我改作業的時候就不確定這些錯誤他們之後會不會修正。若是調整成寫完作業之後自己先改一遍，一來我可以省時間，二來也可以在看作業的時候知道他們有沒有先檢討過，挑出其他小錯誤就好。

也應該針對作業錄一個檢討影片，講一些常見問題，然後從頭示範一次作業給他們看。

第三，針對第三期常卡關的地方以及沒講清楚的概念做加強。其實這我已經有在做了，例如說：

  1. API 觀念不熟，寫了：從拉麵店的販賣機理解什麼是 API
  2. Session 與 Cookie 搞不清楚，寫了：白話 Session 與 Cookie：從經營雜貨店開始
  3. 非同步不熟，寫了：JavaScript 中的同步與非同步（上）：先成為 callback 大師吧！

但還是有加強的空間，尤其是非同步，應該再多加一個單元特別講。CSS 的部分也講得有點少， 要嘛自己再補充，要嘛多貼一些參考資料給他們看。在 JS 進階觀念那邊也應該多加一些應用的例子，例如說 this 到底用在哪裡？closure 用在哪裡？

第四，更貼近業界的作業

實際出去工作之後，其實很難讓你從零開始建一些什麼東西，比較常見的是維護現有的程式碼，所以需要的技能其實是快速掌握現有程式碼以及擁有修改的能力，簡單來說就是看 code 跟改 code，而不是從零開始寫 code。

針對這個，我想設計一系列作業是直接給一個專案，然後要學生去修 bug 或者是新增功能。這一定超有趣，而且優點很多，在改 code 的時候要符合原本專案的 coding style，每個人的改法可能會不同，交完作業可以互相參考學習。

不過我之前有考慮把這個獨立出來變別的計畫就是了，放在程式導師實驗計畫裡面好像會把時間拉太長，獨立似乎比較適合。

第五，改良 final project 機制。

以往 final project 都是非強制的，可做可不做，所以滿多人其實不會做的。但其實有個比較完整的作品，對於第一份工作來說在求職時滿加分的，所以我有兩個想法。

第一個想法是乾脆期末來弄個 hackathon，花兩三天讓大家聚在一起把 final project 的雛形做出來，有了起頭之後要加新功能也比較容易。

第二個想法是我自己先想好幾個專案然後跳下去帶他們做，我算是當 PM 之類的，先幫他們把規格弄好然後 wireframe 稍微畫一畫，其他功能實作都交給他們。

這樣的話應該會增加 final project 的完成率。

第六，課程相關教學影片翻新

有些第一期或第二期直播就講過的概念我有點偷懶，就直接讓學生看直播影片的存檔了，但其實這樣不太好，應該要像其他課程一樣好好規劃課程進度與課綱，錄一個完整的線上課程影片，這樣成效會好滿多的。

第七，把計畫改名

計畫名稱好長，我想改一下名字，但目前還不知道要改什麼。

未來走向

如同另外一篇文章：《閉關修煉，一年後見》所提到的，之後我會休息一年，這一年之間 Lidemy 還是正常運作，問我問題一樣還是會回，不用擔心。我自己也有一些新課程的 idea，因為怕自己拖延症發作，所以決定在這邊先講出來：

  1. CS50 輔助課程：以自己的話把 CS50 教的東西再教一遍並且做補充。以前有做過導讀，但導讀只是帶大家稍微理解，而輔助課程的目標是只看這堂課也可以完成 CS50 的作業。
  2. Xojo 教學課程：我自己是從 VB2005 開始入門寫程式的，過程十分愉快，拖拉式的 GUI 加上簡單的程式碼，讓我認為這比其他程式語言更適合拿來當作新手入門的教材。而 Xojo 的前身是 REALbasic，與 VB 十分類似，又是跨平台的開發工具，我想讓大家透過 Xojo 學會「寫程式」。
  3. 先別急著寫 leetcode：如同我之前在《程式解題新手入門注意事項》提過的，我認為對有些人來說寫 leetcode 還太早，去看演算法相關書籍也還太早。如果連印出九九乘法表都不會，那我不覺得去學 DP 跟 IDA* 對這個問題有幫助。因此我想出一堂課程帶大家寫寫「水題」，確保基本的題目都 ok，再去學那些經典演算法。

以上三個課程都會是免費的，因為我自己認為這些概念很棒，很想推廣給大家，收費會讓事情變得麻煩許多。不過現在這三個課程都只有 idea 而已，連個雛形或是大綱都還沒有，若是你對以上課程很期待，歡迎填寫 Google 表單，每次有回應我就會收到信，就會有種被催促的感覺，就不敢拖延了。

接著，關於程式導師實驗計畫，如同我之前說過的，目前沒有開第四期的打算。因此想要學習程式的朋友們，頂多只能買買 Lidemy 的線上課程而已。

也因為暫時沒打算開第四期，因此我決定分享一些我個人推薦的學習資源。

第一個是網頁切版以及 CSS 的相關資源，因為我個人極度不擅長這一塊，所以在我的教學中也講得比較淺。這邊推薦 Amos 大大的教學影片以及文章：史上最完整的新手網頁入門學習地圖  —  金魚都懂的網頁學習路徑懶人包。

第二個推薦的是六角學院，但課程部份因為我沒有上過，所以無法評論。我推薦的是這個學院能夠為你帶來的資源以及社群。

無論六角的課程適不適合你，我都很推薦你買一堂課，然後加入六角這個大社群。以台灣本土的程式線上課程來說，我認為六角是做得最大、最多，也一直有在做事情的。無論是之前的時光屋或者是之後的揪團寫文章以及鐵人賽，六角一直在想辦法推陳出新，藉由一系列的活動讓學生成長。

總結

這一期比上一期的長度多了兩個月，但最後對於求職的成功與否似乎沒有顯著的影響。若是要說這一期最大的收穫，大概就是深刻理解到「程式基礎」這件事情的重要性。

我原本認為不用特別鍛鍊這一塊，藉由課程中的作業就可以慢慢培養，後來發現特別鍛鍊還是有其必要性，作業中能夠學到的有限。會寫網頁，不代表會寫程式，就算你用 JavaScript 加上互動式的功能了，就算會用 React 了，你也不一定會寫程式。

這部分還是要一步一步來，路才會走得比較順。就像我上面提到的一樣，以後打算出兩個免費的線上課程解決這問題，這樣子這兩門線上課程就會變程式導師實驗計畫的前置課程，必須先上過這兩堂或是通過測試才能報名前端的導師實驗計畫。

如此一來，就能確定學生都把基礎打好了，才開始學前端，我就不必再擔心程式基礎相關的問題，也能把課程定位的更明確。以後那兩堂線上課程就是給「毫無基礎的初學者」上的，而這個轉職的計畫則是給「有程式基礎的人」。

在這三期之中，我一直試著改良課程，讓「毫無基礎的初學者」也能上課，但在第三期結束以後，我認為這樣的方向或許是錯的。若是真的想要讓「所有毫無基礎的初學者」都能夠透過這個課程學習到如何當一個工程師，那勢必要把時間再拉長，然後再補充更多「基礎程式能力」。

可是一旦這樣做了，對原本就有基礎的人來說就太慢了，就變得有點拖。所以目前我認為可以嘗試的一個解法是：

  1. 對毫無基礎的初學者，先教怎麼寫程式（透過 Xojo 教學課程）
  2. 再利用一些有趣的題目，培養程式邏輯思維（透過先別急著寫 leetcode）
  3. 最後才學習前端相關技能，轉職成網頁前端工程師（透過程式導師實驗計畫）

簡單來說呢，我之前不是有說過程式導師實驗計畫不是一堂適合初學者的課嗎？以前我一直想讓這個計畫變成「適合初學者」，但我現在想要讓這個計畫「就是不適合初學者」，然後額外再開一堂別的課程讓初學者學會寫程式，並且學習到適合參加程式導師實驗計畫的程度。

在這八個月裡面我學到了許多，對於課程上的規劃也有了更多想法，很感謝這一期的每個學生，也感謝他們曾經寫過的心得，這些回饋都能讓課程再變得更好。

以上是第三期的成果報告外加未來走向，也算是我對第三期的心得，若是你想知道學生的心得，可以看這邊：https://github.com/Lidemy/mentor-program-3rd/issues。

感謝所有期待以及參與這個計畫的人，雖然不知道是多久以後，但我們下一期見！