Huli's Blog

Learning by sharing

Lidemy 鋰學院是一個為初學者而生的線上程式課程平台,希望能以淺顯易懂的教學,帶領初學者更快速地入門程式設計。你可以直接到網站註冊,或者是追蹤 Lidemy 的粉絲專頁,就能搶先得知課程的最新消息

自學、哲學、講學:我的程式之路(上)

| Comments

前言

無意間看到一篇文章在分享自己學網頁的歷程與心得,而這類型的文章其實我也曾經想要寫過。

在我寫十年程式自學之路的時候,其實我原本想寫的是像剛才提到的那樣,有許多篇幅在講述自己學程式的經歷以及做過的事。可是我寫一寫發現那時候徵文的主題其實是自學的一些心得,所以才改成後來大家看到的那樣,著重在十年裡面學習到的經驗。

這一篇其實算是個人傳記,在動筆之前想到了以前看過的經典文章:追求神乎其技的程式設計之道,風格大概會比較像那樣吧!就是詳細地紀錄了自己一路上究竟學了些什麼,是怎麼走過來的。

這篇最難的部分大概就是標題了,原本想取叫:「十年程式之路」,發現跟上一篇太過於類似,可能會有人以為是同一篇。幸好靈機一動想出來現在的這個標題,但其實「講學」這個詞用得有點過了,在這邊先跟大家說聲抱歉。講學純粹是為了跟前面兩個「學」相互呼應,我不認為我有到講學的程度,頂多就是分享一些經驗跟教學而已。

好了,前言差不多就到這邊。因為這系列會很長,所以拆成上中下三篇來寫。

一場三十人的免費程式教學實驗:成果與檢討

| Comments

緣起

在三個月前,我在 ptt 上 po 文([分享] 免費程式教學(前端)),說我願意提供一系列的免費程式前端教學。只要是有網頁基礎的都能夠報名,歡迎大家寫信給我,並且附上幾個提問的回答,最後我會挑 5~10 個人進行培訓。

上面所指的提問如下:

  1. 自我介紹(例如說背景、怎麼學程式的、程式能力到哪)
  2. 學程式多久了,當初為什麼會想學程式
  3. 現在在工作嗎?是的話工作內容大概是什麼?
  4. 最近碰到過的一個最難的程式問題
  5. 希望我可以給予哪方面的協助

那篇文章是 3/2 發出的,報名截止日期到 3/11,而 3/15 以前會寄信給被我錄取的人

先來講講當初為什麼會想要開這個免費程式教學吧!其實原文裡面也有寫了,我再講得更清楚一點

在這之前,其實我就曾經辦過類似的活動了,雖然也是程式教學,但其實來找我的都是毫無經驗的初學者,我能給的都是一些比較大方向的建議,例如說跟他們介紹什麼是前端、什麼是後端,介紹幾種程式語言,並且推薦給他們適合初學者的。

上一次教學大概接觸了十幾個人,可是卻幾乎沒有一個「真正碰到寫程式」,都僅止於「想學程式但又還沒開始」的階段

可是這不是我想要的,我想要的是實際讓學生們動手寫程式,並且驗證看看「我的方法」是不是真的有效,至於這個方法是什麼,我們稍後會提到。因此,我這次的教學才會把學生限定在「有前端程式基礎」,那代表我可以往更深的地方去教。

爆炸的信箱

文章 po 出之後在 ptt 上的迴響還行,大約是 30 幾個推,以軟體工作版這種比較小的板來說算多了。但事實上,報名的人數遠出乎我的意料。

到報名截止日期為止,我一共收到了 42 封信。

是我原本想收的人數的四到八倍左右(原本我只想收 5~10 個),而且有很多人都寫得很不錯。其實,從這些信件就可以看出每一個人的個性了,有些人比較懶,隨便寫個三四行就寄過來;有些人很認真,甚至還提供履歷或者是有精心排版。

那怎麼辦呢?我要怎麼從裡面篩出我要的人?

算了,太麻煩了,乾脆就全收吧!

沒錯,我真的是這麼想的。於是,拒絕掉真的不適合的 4 個人以後,最後錄取的有 38 人。

下面附上我當初寄給所有人的錄取通知:


Hi,

收到這封信,就代表你已經錄取了。

但其實說「錄取」我自己也覺得有點怪啦,因為並不是什麼正式的活動,辦這個程式教學的初衷就純粹是我希望四五年前我剛接觸前後端網頁程式的時候,也有人能夠這樣帶著我,給我一些建議。

但那個人始終沒有出現,於是在四五年過後,我決定自己跳下來做那個人。

在寫程式的路上一樣受到了很多前輩們的幫助,Google 跟 Stackoverflow 也惠我良多,就是因為受過太多人的幫助,才讓我一直覺得「回饋」是一件我必須要做的事情。

前言差不多就到這邊了,這封信是統一回給大家的,接著會介紹一下之後這個活動的走向。

這次的報名比我想像中的踴躍,大約有 40 位朋友們都對這個活動有興趣,雖然當初文章寫說只收 5~10 位,但仔細考量過後,發現其實每個人的需求都不太一樣,基本上可以把需求分為兩類。

第一類是想要練習前端基礎,希望我能夠出作業或是給一些指導的;第二類則是已經有前端的程式能力,希望能跟我聊聊工作上相關的事情,例如說我是怎麼到新加坡工作,要達到什麼樣的程度等等的。

針對這兩類的需求,會分為兩種方式來進行。

第一類的話大約每週或是每兩週會出一次作業(或者是之後有可能改成作業全部都先出好,大家自己可以有自己的進度),然後固定時間我會統一講解這次作業裡面你應該可以學習到的知識點,再加上我自己的一些補充。

第二類的話基本上能力沒什麼問題,我也沒有甚麼可以教的,所以主要就是跟你們約個時間,然後我們來聊聊天,就當作是參加什麼技術分享會跟隔壁的人聊聊天就好。不用有什麼太大的壓力,聊一聊也可能發現其實你的技術能力比我強。

大家都已經有寄信對我做個簡單的自我介紹了,現在換我來做個簡單的自我介紹。

我叫胡立,現在在新加坡擔任前端工程師,來這邊大約五個月左右而已。

學程式是從升國中的時候開始,一路上基本都自學,小時候寫 VB,長大之後跑去玩程式競賽寫 C/C++,之後對手機程式有興趣跑去寫 Java, Android,大學時終於踏上網頁之路學習 PHP 跟前端網頁。實習時候發覺自己對前端比較有興趣,就開始比較專攻前端以及 Node.js 後端開發

更詳細的資料你可以參考我的 Linkedin:https://www.linkedin.com/in/hulii,之後的交流大家也不用太嚴肅,就叫我 huli 或是胡立就好,太嚴肅的話我也會覺得怪怪的XDD

有關於這個教學活動,還有以下幾點要跟大家說明:

  1. 你可以「隨時退出」,因為你有可能把我想的太強,但實際教學時卻發現我好像沒那麼強,就跟你的期待有落差。如果碰到這種情況,覺得我沒有辦法給你什麼幫助的話,那你可以直接來跟我說或是怕尷尬的話隨便想個理由也可以。這沒什麼的,不用有什麼壓力。

  2. 一定要給我回饋。無論我教得好或是壞,都麻煩大家給我一點回饋,我之後會開一個匿名的 Google 表單讓大家填寫,還麻煩大家在教學結束之後給一下 feedback。

  3. 學習還是要靠自己。儘管我可能會給你一些方向,給你一些建議,但畢竟師父領進門,修行在個人,你們之後會變得怎麼樣,就看你們自己了。

就差不多是這樣了,在這邊有兩件事情要請大家幫忙,才能讓我們順利開始

  1. 加入 Slack(沒用過的可以自己去 Google 一下教學)
  2. 在 Google 表單填寫基本資料(這超級重要,一定要填)

以後 Slack 就是我跟大家溝通的管道了,所以麻煩 Slack 的通知要開一下,如果我在 Slack 上面一直沒回你的話,可以多找我幾次或是一樣寫 email 給我。

現在離四月大概還有三週的時間,我會在這段期間內盡量找「每一個人」聊一聊,如果你是第二類,就是想跟我聊一聊的話,那我們的緣分(?)大概就是聊完就結束了,因為之後我也沒有什麼可以幫的了XD

如果是第一類需要教學的,就大概根據你之前的那篇自我介紹簡單閒聊一下,也會聊到目前對這個教學活動的期待以及更具體地、希望我能夠給予的幫助,教學部份的話預計是從四月初開始,我會再找時間統一跟大家 update 一下最新的狀況。

下面附上初步想出來的第一類的教學大綱,如果你覺得下面這些你都會了,那其實沒什麼必要聽我教學,因為我能教的就這些了XD

我擅長的比較偏 js 而不是 css,所以期待能學到什麼厲害 css 技巧的朋友們可能會失望了,我自己也不太會切版,RWD 也會苦惱很久,在 css 這部分比較不能提供什麼協助。

  1. 練習實作 Twitch 遊戲畫面排版(知識點:基本 html, css)
  2. 讓畫面變得更動態(知識點:css transition)
  3. 改用 Less, Sass 或是 Stylus(知識點:css 預處理器的使用)
  4. 串接 Twitch API 拿取資料(知識點:看懂 API 文件、API 串接、Ajax、CORS)
  5. 優化:加上 infinite scroll 與 placeholder(知識點:infinite scroll, placeholder)
  6. 改用 vanilla js 實作(知識點:vanilla js)
  7. 加上多國語言(知識點:i18n, library)
  8. 把 CSS, JS 全部都 inline 到 html(知識點:gulp、為什麼需要 gulp)
  9. 我們為什麼需要用 Webpack?(知識點:webpack)
  10. 改用 React.js(知識點:React.js) (視情況增加 Redux, React-router 等等的教學,因為教學內容可能會變,就沒有先規劃那麼多)

最後幫大家條列式總結一下現在狀況:

  1. 加入 Slack,填寫 Google 表單
  2. 跟每個人都會先聊聊,但你可以選擇聊完後你要不要參加我上面那些程式課程(就是選第一類的意思)
  3. 等待我主動跟你聯絡敲時間在線上聊個天
  4. 聊完以後等待通知開課

感謝大家的配合,
Huli


一開始的兩週我大概跟 20 個同學一對一聊過了,大約七成用語音三成用文字,就聊一聊彼此的狀況、從什麼時候開始學程式的、程式程度大概到哪邊以及對課程大綱的看法。

其實這個課程最重要的就是課程大綱了,我們馬上來仔細看一下!

課程大綱背後的涵義

會擬出這個課程大綱,主要有兩個因素,第一個是因為裡面教的那些東西,剛好都跟我近期的工作內容有相關,因此教起來我會比較得心應手,畢竟自己就在碰這些東西。

第二個原因是因為我在工作上接觸到這些東西的時候,我原本也是什麼都不懂,不知道 webpack 在幹嘛、不知道 gulp 在幹嘛、不知道 infinite scroll 到底怎麼做。可是當我花一段時間理解之後,我知道為什麼當初的我覺得這麼難了。

因為我不知道是用在哪裡,我不知道是幹嘛的,或是說,我不知道「我為什麼要用」,我在網路上找了一大堆教學,每一篇都在跟我說「怎麼用」,卻很少有資料能告訴我:「為什麼要用」、「如果不用會怎樣」

在幾次教學經驗的累積過後,我找到一個我認為比較有效的教學方式,原則就是:

要先痛到,才會得到

這是什麼意思呢?

我有一陣子很喜歡看大公司的一些架構文章,裡面寫說他們怎麼把機器架構調整成適合規模化,講說他們碰到了什麼問題,用什麼解法解決了超大資料量所帶來的 Bug。

我一開始覺得很有收穫:「哇,這些感覺好厲害啊,學到很多」。可是過一陣子之後,才發現自己什麼都沒學到。那些東西過一週之後我就全部忘掉了,好像文章根本沒看過一樣。

後來我忘記在哪邊看到一篇文章,裡面有一段傳達的意思我記得特別深刻(如果有人也看過同樣一篇,麻煩在底下留言,小弟感激不盡),文章裡面寫說,那些都是大公司的高手們痛苦過、經歷過所淬煉出來的「精華」,你怎麼可能期望你看了十分鐘,就能夠擁有他們十年的功力?

「痛過」,是一件很重要的事。

與其直接教他們寫 SCSS,不如先讓他們寫 CSS,然後一直叫他們改顏色,叫他們改東改西。這時候他們就只能一直用文字編輯器尋找->取代,不斷重複這個循環。等到你確認他們真的痛了,再教他們 SCSS。

這時他們會有種「重獲新生」的感覺,「靠!原來還有這種東西喔,這樣就不用改這麼辛苦了,用變數就可以了」,這樣子的學習方式我認為會比起直接教有效許多。

在教他們一樣東西之前,我一定會想辦法讓他們知道說:「為什麼我需要這個」,我認為當這個問題搞懂也同意之後,才會更有動力去學習,也才能知道自己到底在學什麼,學了之後可以幹嘛。

還有另外一件事,那就是比起每一個不同的小作業,比較好的做法是「一個逐漸加強的作業」,這樣在做作業的時候,學生可以不斷地看見自己的進步,不斷地看見專案的成長,而且最後會做成一個完整的,而不是一堆零碎的、破碎的小專案。

因此,我就以這幾個概念規劃出了這些課程大綱,後來有稍作調整:

  1. 基本 HTML/CSS 練習:以 Twitch 為例
  2. 讓畫面變得更動態:神奇的 CSS transition
  3. 寫 CSS 必備神器:CSS 預處理器
  4. 從假資料到真資料:Ajax 與 API 串接
  5. 讓網頁變得更完整:加上 placeholder 與 infinite scroll
  6. 返璞歸真:vanilla js
  7. 走向國際:i18n
  8. 當我們包在一起:Webpack
  9. 節省 Request 的極致:一為全,全為一
  10. 改掉你的壞習慣:ESLint 與 standard

第十週原本是 React.js,我後來拿掉了,原因有兩個。第一個是我認為 React 放在這邊不適合,還沒到教的時機點,還不夠「痛」,而且跟前面的也沒有什麼關聯。第二個是我改作業發現很多人的 coding style 不好,所以第十週放這個,前面九週作業寫得越醜的要花越多時間改,讓他們「痛」一下。

我必須先承認,上面這個規劃並沒有很好地使用到「痛到才會得到」這個教學原則,這個是我還可以再做得更好的部分,進步空間還很大很大。

而由一個小作業逐漸加強我覺得我算是滿好的掌握到了,一開始先讓他們刻一個靜態版面,再來把 CSS 換成 SCSS,然後把假資料換成真的資料,串 API。接著加上佔位圖以及無限滾動,讓頻道可以一直滾動加載。

第六週的作業目的是拋棄 jQuery,節省檔案大小,也讓他們知道原來不靠 jQuery 還是可以寫 JavaScript 的。第七週把中文換成中英雙語,可以支援兩個語言,第八週改用 webpack 實作模組化,第九週用 gulp 讓他們知道原來很多事情都可以自動化,最後一週修正自己的 coding style。

這樣子逐漸優化的過程,他們在做下一個作業的時候就可以直接接續上一個,把一個專案變得越來越完整。

解決問題

如同我一再強調的,寫程式不是重點,重點在「解決問題」,幾乎所有事情的重點都在這個。

解決問題又可以分成以下幾點來思考:

  1. 你要解決什麼問題?
  2. 你用什麼方法解決?
  3. 這個方法有什麼優缺點?

我很喜歡一個詞叫做 trade-off,中文可以翻作:權衡、取捨。

尤其是在寫程式的領域中,你做什麼事其實都是一種 trade-off,最常見的例子就是時間換空間或空間換時間,沒有那麼好康的事情讓你又有空間又有時間。好啦,其實有,但那都是用錢換來的。

我在每一週的作業說明裡面,都會提到說我們這週碰到了什麼問題。那解法呢?解法當然就是那一週要教大家的東西囉。以下我們把每一週的課程再剖開來看,自問自答上面那三個問題(解決什麼問題、如何解決、優缺點):

基本 HTML/CSS 練習:以 Twitch 為例

  1. 解決什麼問題:我想有一個頁面可以看 Twitch 頻道
  2. 解決方法:自己寫網頁
  3. 優點可以客製化,缺點是花時間

讓畫面變得更動態:神奇的 CSS transition

  1. 解決什麼問題:想要加上效果讓頁面更精緻
  2. 解決方法:用 css transition 這個屬性來做漸變效果
  3. 優點是有了漸變效果,缺點是可能有效能問題

寫 CSS 必備神器:CSS 預處理器

  1. 解決什麼問題:寫 css 太麻煩,想要有像程式那樣的變數可以使用
  2. 解決方法:用 css 預處理器
  3. 優點是方便維護,缺點是需要多一步 compile (像這個時候,就必須衡量優缺點,在這邊顯然優點大過於缺點,因此我們有一個「好理由」採用這個解法)

從假資料到真資料:Ajax 與 API 串接

  1. 解決什麼問題:現在的資料都是寫好的,我想要有真實的資料
  2. 解決方法:串接 Twitch API
  3. 優點是資料變真的了,缺點是看到畫面的速度變慢 (如果你要解決這個問題,必定要串接 API,因此這邊的缺點其實可以忽略)

讓網頁變得更完整:加上 placeholder 與 infinite scroll

  1. 解決什麼問題:一次載入 100 個頻道太慢,並且在載入時會跑版
  2. 解決方法:採用捲動到底才載入新頻道的方式,並且加入佔位圖防止跑版
  3. 優點是使用者體驗變好、首次加載變快,缺點是 request 數量變多了

返璞歸真:vanilla js

  1. 解決什麼問題:jQuery 檔案大小太大,想減少 request 大小
  2. 解決方法:把 jQuery 拿掉,不依賴任何 Library
  3. 優點是檔案大小減少,缺點是程式碼複雜度提高,必須自己處理跨瀏覽器問題

走向國際:i18n

  1. 解決什麼問題:想要新增一種語言
  2. 解決方法:把語言放在語言檔裡,引入之後靠 window 這個全域變數傳遞
  3. 優點是可以有多個語言,缺點是污染全域變數

當我們包在一起:Webpack

  1. 解決什麼問題:解決上一次作業的全域變數污染,以及想要使用 require 的這種語法
  2. 解決方法:導入 webpack
  3. 優點是模組化開發,缺點是需要多一層打包,以及檔案大小增加

節省 Request 的極致:一為全,全為一

  1. 解決什麼問題:Request 太多
  2. 解決方法:把 JavaScript 跟 css 全部 inline 到 html
  3. 優點是減少 Request,缺點是開啟頁面的時間變慢

改掉你的壞習慣:ESLint 與 standard

  1. 解決什麼問題:寫程式碼的習慣不好,不利於團隊開發
  2. 解決方法:導入語法檢查工具
  3. 優點是統一程式碼規範,缺點是...好像沒什麼缺點

比起「webpack 是一個打包工具」這種介紹,你讓初學者們知道 webpack 到底是幹嘛的、是要解決什麼問題、要怎麼解決會有用的多。再次強調,問為什麼很重要,知道為什麼也很重要。知道背後的原因,你就可以決定你要不要用這一套解法。

你用一個東西,背後必須要有一個「好理由」。

A:我們改用 TypeScript 吧
B:為什麼?
A:因為潮啊!

如果「潮」這個理由不夠有說服力的話而 A 又提不出其他更好的理由,那就沒有必要改用 TypeScript。

之前有一篇很紅的文章,叫做:在 2016 年學 JavaScript 是一種什麼樣的體驗,我覺得有一個很可惜的點,那就是有些人看完之後的心得都只有:「唉,對啊!前端現在也太複雜了吧!」

但我覺得這篇文章你應該去思考的是:「裡面那些工具是不是真的需要用到?那些工具想解決的問題,到底是不是我碰到的問題?」,這才是這篇文章的重點。

舉例來說,裡面有一段這樣寫:

可別用 jQuery!現在哪還有人用 jQuery。現在是 2016 年了,你絕對應該用 React。

這個理由跟上面的一樣薄弱,一個字:潮!

當然,他也可能是其他意思,也有可能是想表達說 React 是近年趨勢,jQuery 可能會慢慢被淘汰並且不再維護,以後就有維護性的問題。這時候你就可以考慮說:這樣的情形是不是有可能發生?如果真的發生的話,會有怎樣的影響?用 React 帶來的複雜性跟 jQuery 的可維護性哪一個損害較小?

總之呢,重點應該是「你要解決什麼問題,這問題用哪些工具來輔助最適合」,而不是一味的覺得前端怎麼那麼複雜那麼多東西。

是啊,本來就一堆東西啊,可是裡面可能有八成你根本用不到啊!

如果你寫一個一頁式的行銷 landing page 還硬要用 React + Redux + Rx + Webpack 的話,那我也是醉了。

課程進行方式

這堂課程的進行方式是這樣的,如上所述,總共十個作業,每一個作業一週,必須「先做作業」,但做不出來也沒關係。每個禮拜二我會直播講解上一週作業並且實際示範如果是我的話,我會怎麼做。

會這樣規劃是因為「自學」無論在哪個領域,都是一個重要的技能。我想先讓同學們對於我要教的內容有概念,甚至是把作業做出來以後,我再重新講解一遍。我覺得唯有這樣,才能讓同學們對我教的東西更熟悉。

這就呼應到我上面提過的「要先痛到,才會得到」,事後有很多同學都反應他們課前預習時覺得有些東西好難,怎麼看都看不懂。可是一看完我的直播教學,就有種茅塞頓開的感覺:「哇!原來這麼簡單」。

如果相反過來呢?假如是我先上課,他們就只會覺得:「喔,是這樣寫」,接著寫作業的時候就直接抄我的解法就好了。他們學到了什麼?學到模仿我的程式碼,然後過一個禮拜完全忘記這個解法。為什麼?因為他們沒有痛過,所以沒有去思考。

來,再次強調,你寫程式的時候要思考!要思考!要思考!只有思考過,深思熟慮過的東西才是你的,你才記得住。

課程成效

講完了課程大綱的設計理念,以及我自己在這堂課最想要傳達的核心思想之後,該來談一下這堂課程的成效了。

前面有說到一共 38 人收到錄取信,到後來只有 36 人填寫基本資料,兩個人就這樣消失了。

而這 36 人之中,只有 26 人有完成第一次作業,意思是說,有 10 個人連作業都沒做,28% 的人就這樣不見了。因此之後的數據我會把參與這次課程的人數調降為 26 人。

能夠撐完十次作業的,只有 8 個人而已,大約是 30%。

下圖是每一次作業完成的人數

可以看到掉得最多的一次是 hw2 -> hw3,寫 CSS 必備神器:CSS 預處理器,我也不知道為什麼這一週會掉這麼多人。

課程結束之後的問卷回饋,作業沒有做完的理由有:時間無法配合、作業難度太高、懶惰、有其他事情、沒興趣。

而問卷中有一題是:「覺得難度最高的作業是哪一個?」,大多數人的回答都是 hw5(讓網頁變得更完整:加上 placeholder 與 infinite scroll)跟 hw6(返璞歸真:vanilla js),因為以前完全沒有寫過類似的東西。

如果以後要改善的話,可以把 hw5 再細切成幾個單元,而不是一次就完成這兩項,hw6 也可以用類似的方法,這樣對學生來說應該就不會一下子難度跳這麼多,而是慢慢變難。

學員回饋

課程結束之後有請大家填了一下回饋的表單,很幸運地,大家感想都滿多的。我原本想要把原文全部貼上來,但這樣篇幅會太多,有點妨礙閱讀,因此我只擷取部份,刪除掉一些重複的內容。

老師在講解或改作業時有什麼優點?

(以下皆為回饋原文,我只修了一些排版而已)

  1. 講解的部分使用 Youtube 直播可以方便學生彈性安排時間聽課。講解的內容有個很大的優點就是 Huli 會用非常淺顯易懂的例子與概念切入,讓自己有時候花了一兩天寫的作業,聽完講解後覺得「哇靠原來這麼沒有想像那麼難」,而每一堂講解的編排有組織性,也很容易整理筆記。改作業的部分,Huli 會仔細看我有列出的 troubleshooting 並提供有用的建議,也會在做的不錯時給予滿滿的鼓勵,這對新手入門算是很棒的引導。
  2. 講解的時候講到很多我原本準備好要問的東西,而且講解方式很容易讓人理解,因為有交代原因,所以也很容易讓人接受。就像安排課程一樣,每個章節循序漸進,就會很容易理解以及接受為什麼要用這些東西,以及這些東西的好用之處。
  3. 雖然我只有交前面幾次作業,不過可以看得出來有用心在看作業。講解方面,我覺得非常好不會突然出現尷尬的時候,也講得很清楚!
  4. 直播完整程式 live coding 過程,包括用terminal執行指令,讓我這個 terminal 生手不再害怕使用 terminal,也對它越來越熟悉了,是這次程式課後的額外驚喜收穫。講解程式會讓人覺得原來寫程式可以這麼清晰簡單,講解過程看似輕鬆卻有架構。當同學聽不懂時會用很多不同角度切入解釋,像是生活化例子或是各種相關連結以加深同學對程式的觀念和印象!

老師在講解或改作業時有什麼缺點?

  1. 感覺上沒什麼缺點,如果要說可以更好的地方的話,感覺上 IDE color theme 可以用字與背景對比強一點的,觀賞上能增進使用者體驗。不過整體而言不成大礙。
  2. 可以的話,可以準備個 txt 檔案把當天要說的重點寫上去順便當標題XD
  3. 當課程內容如 webpack 和 gulp 是我完全陌生的東西,也沒碰過 node.js 下,聽起來就會覺得講解速度較快,尤其直播課時會說這 webpack 和 gulp 作業算很容易,就會讓初學 node.js 的我有些感到挫折...希望自己能培養對新事物有更快速上手的能力。
  4. 這倒不算是缺點,只是小建議。如果要在直播時節省時間,可以先在直播前把可能需要用到的網站先放在瀏覽器。不過直接在直播時搜尋的好處是,我們事後要搜尋可以知道你利用什麼關鍵字去搜尋。

課程心得

回饋問卷裡的心得礙於篇幅,貼在這邊不太適合,因此我只貼兩篇寫在自己 Blog 的。

  1. Frontend Intermediate Course - 學習心得
  2. 心得|Huli's Frontend Intermediate Course|緣起與收穫

自我檢討

先來說缺點的部分,其實比起優點,我更想聽到的是缺點。因為知道缺點在哪邊才能持續改進嘛,但不知道是這次表現太好還是學生不好意思,缺點的部分回饋的比較少。

身為一個不斷追求進步的老師,就算學生沒講,自己也應該要察覺到一些缺點。

1.改作業有時候馬馬虎虎。

雖然學生說改作業很用心,但其實有時候我一次面對堆積如山的十幾個作業,很多東西都只是快速看過去而已,畢竟老師也是會懶惰的...這是我之後可以再改進的地方

2.課程規劃不夠「痛」

上面我有提到要先痛過才能理解,我覺得作業還可以再切得更細,讓學生更「痛」一點。例如說培養 coding style 的部分,可以先出一個作業規定大家:「變數名稱只能用一個英文單字,例如說 a, e, y 等等,不夠用的話加上數字變成 a0 等等」,做完一次作業之後,隔週再讓大家看自己上週寫的程式,應該會發現看不懂在幹嘛。

這個時候,他們就會知道變數命名的重要性了。

接著談談優點,開頭有提到說這是一場:「三十人的教學實驗」,實驗目標就是驗證我上面講的那些教學理念(要先痛過、要懂目的、要知道為什麼)是否真的能幫助學生學習。

從學生反饋的結果看來,我認為是可以的,這也更加確認了我以後課程的規劃方向。

有關優點的部分,我就直接貼幾個學生的回饋上來吧!從這些回饋裡面就可以發現,我想傳達的,他們都能夠確實接收到。

  1. 講解的時候講到很多我原本準備好要問的東西,而且講解方式很容易讓人理解,因為有交代原因,所以也很容易讓人接受。就像安排課程一樣,每個章節循序漸進,就會很容易理解以及接受為什麼要用這些東西,以及這些東西的好用之處。

  2. 講解程式會讓人覺得原來寫程式可以這麼清晰簡單,講解過程看似輕鬆卻有架構。當同學聽不懂時會用很多不同角度切入解釋,像是生活化例子或是各種相關連結以加深同學對程式的觀念和印象!

  3. 很喜歡老師的教學是讓同學先寫再公布答案,讓同學有機會先嘗試各種自己先想的到或找的到的可能解法,而等到直播課時才公布老師的做法,可以有互相交流切磋的機會,也不會讓同學是腦袋空空去上課。因為都先寫好作業了,在課堂上也更易吸收和整合,也能馬上快速理解哪種情境適合哪種解法,也能一眼發現自己先前卡住的地方在哪,因為都已經卡過了。

  4. 在這次程式課也發現寫程式這件事的思考沒有想像中的複雜,可能和老師的教學大綱切的清楚乾淨,以及講解時是以「需求」為出發點。一些新手,像是我,常常在開發過程花了一堆時間,總是在寫連自己也不太懂自己幹嘛或為何而寫的code。寫code時的思考是我在這堂程式課學到的珍貴收穫。

總結

先感謝我的學生們,陪我走過了十週的課程,並且願意在結束之後給予回饋。

我一直覺得,程式教學應該要能有更好的方法,能夠幫助學生更快上手、更快理解。這次的課程讓我驗證了我目前的方向是對的,之後也會一直朝著這方向前進。

如果你對這次課程感興趣,可以前往課程的 Github 頁面觀看課程內容,或是到Youtube直接觀看影片。

也可以直接到我最近才開的線上課程平台:Lidemy 鋰學院註冊課程,完全免費!我把作業內容跟影片都上傳到上面了。(但因為課程已經結束了,所以沒有人會幫你改作業)

我認為這堂課的價值在於「先寫作業,後講解」的教學模式,因此像上面這樣把教學影片公佈出來,我不打算盈利,都是完全免費的資源,開放大家隨意取用,因為這堂課的核心價值已經不見了,所以也沒必要收費。

我希望我的課程在各個環節上都能夠公開透明,因此,若是對學員課後提交的回饋表單有興趣,這邊有學員回饋的完整備份(只有刪除掉一些個人資料)。

最後,感謝大家願意花時間閱讀這篇落落長的文章,若是對我後續的教學實驗或課程有興趣,麻煩請追蹤Lidemy 鋰學院粉絲專頁,後續的消息都會公布在那邊。

感謝。

[心得] 新加坡看病初體驗

| Comments

事情的開端

事情是這個樣子的,原本我眉毛左邊有長一小粒東西,我想說可能是青春痘所以就沒去管
就在上禮拜日晚上(5/21)覺得那邊有一點腫腫的,想說會不會其實是撞到什麼腫起來
晚上睡覺的時候就想說那我揉一下好了,不是腫起來都要揉一揉嗎
接著我就進入夢鄉了

好戲登場

隔天早上起床,就是見證奇蹟的時候了

[心得] 寫 blog 的好處

| Comments

前言

這篇我原本是回在 ptt 上面的,整理一下之後轉到 blog 來
其實對於這個主題,91 哥的這篇:我為什麼鼓勵工程師寫 blog已經講得很好了,建議大家先看一下這篇文

而我這篇心得文呢,主要是因為看了上面貼的那篇之後滿有感觸的
所以提出幾個自己很有共鳴的點來做延伸

幫助自己

我寫 blog 的最大收穫之一就是幫助自己
很多人都以為寫了技術文章就是要給別人看的,但卻忘記自己也是文章的受眾之一

很多時候我寫 blog 是因為要留下自己的筆記
想說放 Evernote 到時候很難找,不如公開在網路上,還可以讓 Google 幫我備份
而那些筆記對別人有沒有用我不知道,但至少對我自己很有用

有很多不會頻繁接觸的東西,過一陣子沒碰之後你一定會忘記
例如說新電腦的環境設置,我習慣裝 zsh,然後自己改一些配置
可是這種東西一定設定過一遍就忘記了,因此我就整理一下 po 在網路上

前一陣子剛換工作,要幫新電腦設定 zsh 的時候,就跑回去看自己以前的文章

「阿!幸好我那時候有寫下來,這次只要照著做就好了」

或是之前 postgresql 在設定的時候也碰到一些問題,一樣寫了 blog 記錄起來
下一次碰到的時候我完全忘記當初怎麼解了,就會很感謝當時的自己有記起來

又或是最近想寫個 Slack 的 bot 玩玩看,但已經很久沒有寫這東西了
但幸好我 blog 以前有寫一篇 Hubot 的心得,只要稍微看一下,記憶就都回來了

相信我,寫 blog 幫助最大的一定是自己
你看我可以舉那麼多例子就知道,我被自己的 blog 幫助到多少次

若是你在初期真的不知道要寫什麼,沒有什麼 idea 的話
建議你可以從技術筆記開始,可以不用是那麼完整的一篇技術文章
甚至只是整理一些連結也可以!

我以前寫過一篇文章標題叫做:[Android] 到底什麼是context?
裡面我只是整理了一些看到的不錯的連結,當作筆記就 po 在部落格了
結果你現在如果去 Google 搜尋:「android context」,會發現這篇出現在第一頁

只是一篇再簡單不過的筆記,卻帶來意想不到的效果
(但這種奇怪的事不是天天都有啦,當作運氣好的結果就好XD)

再舉一個例子,我當初在理解從 callback, Promise, generator 一直到 async 的時候
有把自己的心得記錄下來整理成文章:[Javascript] Promise, generator, async與ES6

像我現在其實就有點忘記這整個脈絡跟 code 要怎麼寫了
但只要再把文章看完一遍,我就可以回憶起八九成了XD

再一次的學習

理解一項東西是一回事,要寫出 blog 文章又是另外一回事

有時候你在研究一個主題,東看看西看看覺得有點 insight 可以寫
或者是覺得有些心得想要跟大家分享,於是決定立刻動筆開始寫文章

可是,寫一寫卻發現這個點好像不太懂為什麼是這樣,那怎麼辦呢?
還能怎麼辦,只好去查一下再把它弄懂
或者是在文章上面寫:其實這部分我也不是很懂...

但如果沒有弄懂的話,你會發現文章愈來愈寫不下去,因為不懂的地方只會愈來愈多
於是你就只好認命,乖乖的再去把更多的文章看完,補足自己不懂的部分

沒錯!在你終於把文章寫完的時候,你的知識又再消化了一遍,又把更多的洞給補齊
這就是寫文章的好處之一,可以強迫自己再一次學習
說穿了,其實寫文章就是把知識重新整理、歸納的一個過程

像是我前幾天寫的一篇文章:我遇過的最難的 Cookie 問題

其實原本我是沒有想要把問題追根究底解決的,可是我文章都寫一半,頭都洗一半了
文章的結尾如果是:這個問題我也還沒有答案...的話,總覺得不太完整
只好硬著頭皮去找更多資料,最後終於把問題透徹地搞懂

我寫這篇文章主要是想告訴大家,原 po 這篇裡面講的寫 blog 的好處都是真的
因為那些好處我幾乎全部都體驗過一遍了

像是把自己的知識公開在網路上,就可以讓全世界的網友來幫你糾正錯誤
這是一個多棒的機會!有些東西如果沒有人來跟你講,你可能根本不會知道

例如我一個月前寫的:讓我們來談談 CSRF

po 完之後有一個朋友傳訊息給我說:「講 CSRF 居然沒講到 SameSite」
我就傻了幾秒跟他說:咦?這個我居然找資料的時候沒找到!
然後就去把相關知識惡補了一遍,再把內容補上去原本的文章
就這樣,輕鬆再賺到了一個新知識

意外的收穫

我當初寫 blog 的理由就兩個:幫助自己、幫助他人
對我來說,其他額外發生的好處很多其實都是額外價值,但也會成為你繼續書寫的動力

像是以前寫了一篇講 redux 的 middleware 的文章
http://huli.logdown.com/posts/294284

不定時會有路過的網友看過之後來留言,說這是他們找很多資料以後,看過最好懂的文章
這時候內心當然就會小感動XD 至少知道自己的東西是真的有幫助到人
也知道自己真的有能力,可以把一件複雜的事情講的簡單許多

其他的好處像是收到演講邀約、上課邀請甚至是公司的合作機會
或者是聚會時別的工程師會講一句:「阿!我有看過你寫的....」

講到這裡,或許會有人認為說:你能得到這麼多好處,是因為你的 blog 比較多人看啊

聽起來也是挺有道理,可是,如果你不是本來就有名氣的人
剛開始寫 blog 的時候,大家的起跑點都是一樣的,都是 0

我也是一樣,剛開始寫那些筆記的時候根本就沒有人看,也沒有人會來回應
所以這時候我覺得寫 blog 的心態就很重要
假如你一開始的心態就是:「我要靠著寫 blog 成名!」
那這時候你的挫折感就會很大,因為你的 blog 根本沒有人會來看

可是我剛有講過,我寫 blog 的心態是為了要幫自己留筆記
如果有人來看當然很好,但沒有人來看我也沒差,反正我可以幫到我自己就好

但你要相信,真正有價值的內容是不會被埋沒的

如果你覺得你寫的技術文章很棒,真的很有質量,也能夠幫助到很多人
可是卻沒有人知道的話,你可以貼到 Facebook 的技術社團
或者你要投稿 TechBridge 也可以,我們會幫你曝光的XD

我的 blog 有八成的流量都是從搜尋引擎來的
只要你的文章是真的有價值的,就一定會越來越多人點,然後 Google 排名就越來越前面
看的人會越來越多,流量也會越來越多,你就會更有動力寫出更好的文章

這是一個很棒的正向循環,希望大家都能進入到這個循環之中XD

總結

講了這麼多,還沒寫 blog 的人應該對這件事情很心動了
不要再等了,現在就是「好,那我找個時間來寫 blog」的那個「時間」
至少先創一個 blog,大概才花你十分鐘而已

如果你想找一個線上平台,我用了兩年的 logdown(免費版)我覺得很不錯

或者你也可以考慮國外很紅,國內也越來越多人 po 文的 Medium

想要自己架的話可以考慮 Hexo
或其實用 Github Issue 寫 blog 也可以!

不要再等了,讓我們一起寫 blog,一起成長吧

該進大公司還是新創?

| Comments

標題來自於 Rabbie Kao 的個人臉書的這則貼文,建議大家可以先去看一下原文再回來看這一篇。

身為一個比較早出社會的人,最近也剛好有朋友問到我這一題,想說也來發一篇我自己的看法。

你想成為怎樣的人?

首先,我十分認同這個是非常重要的一個問題,是人生中的核心問題。你的重大決定應該都會跟這個核心問題有關,所以這也是為什麼這一題這麼困難,因為它太重要了。

但我認為如果得不出這個答案也是很正常的一件事,也不用覺得灰心什麼的。

有些事情本來就需要透過不斷地探索才知道嘛,隨著你經歷過的事情愈來愈多,也會更知道自己想成為一個怎樣的人。而且這個答案也不是固定不變的,其實也可以變來變去。

你可以十歲的時候想成為一個守護地球的人,二十歲的時候卻變成一個想要毀滅地球的人,這也是 ok 的。

但儘管如此,還是希望大家都對這個問題有一個基本的答案,就是大概模糊地知道自己「目前」想成為怎樣的人,對以後做任何決定都會有幫助。

好了,然後呢?

假設我們已經回答完「自己想成為一個怎樣的人」了,然後呢?我們就可以來回答「該進大公司還是新創」了嗎?

我想成為一個,藉由程式教學讓每個人都不再覺得程式是一件困難的事情,專注在程式教育這塊的人

那我應該要進大公司還是新創?

嗯,顯然是回答不出來的。

為什麼?我覺得是因為在「想成為一個怎樣的人」與「我應該進大公司還是新創」之間有一個 gap,這個 gap 太大導致你沒辦法從這個前提直接導出結論。因為前者的這個問題太核心了,是整個人生價值觀的核心問題。

再者,其實「我應該進大公司還是新創」這個問題其實也問得不好。如果對方真的只問:「我該進大公司還是新創?」這種問題,那我也會覺得這個很空泛很爛。但就算對方這樣問,其實我們也還是可以再追問幾個問題,才會更明白提問者想要問的到底是什麼,例如說:

  1. 你為什麼想(或不想)進大公司?
  2. 你為什麼想(或不想)進新創公司?
  3. 你目前猶豫的點是什麼?

以我的經歷來說,通常會問我這個問題的人,可能是已經拿到一間新創公司跟一間大公司的 offer 了,這時候才會提出:「我該進大公司還是新創」這個疑問。

而他們通常會提出這個疑問,其實背後的點有可能是:

  1. 以職涯發展來說,大公司的經歷會不會比新創更吃香?至少大公司大家都聽過
  2. 聽說新創做的事情比較雜,會不會到那邊之後什麼都要做,反而比較像打雜的?
  3. 聽說在大公司只能當小螺絲,只負責其中一部分,會不會很無聊?
  4. 聽說人很少的小公司因為培養新人的成本很高,來了就不想放他走,是真的嗎?
  5. 在新創公司如果公司倒掉怎麼辦?
  6. 新創公司的升遷跟獎金制度聽說都不完整,那選大公司是不是比較好?

因為原本的問題範圍太大,所以我們必須把這個大問題切成很多的小問題,其實這些小問題才是重點。而且你把這些小問題解決以後,大問題也就跟著解決了。

不只是「我該進大公司還是新創」這個問題範圍太大,「我想成為怎樣的人」這個問題範圍也太大了。

如果以選擇公司的角度,我覺得試著回答以下幾個問題會更有幫助:

  1. 我想進去什麼樣的公司?
  2. 我想擁有怎樣的工作環境?
  3. 我希望的工作內容是什麼?
  4. 我的職涯規劃是什麼?

當然,這三個問題跟「我想成為怎樣的人」也是有關聯的,例如說你想成為一個很注重環保的人,你就會比較想進去標榜 Eco-friendly 的公司。或是你想成為 40 歲就退休的人,你在職涯規劃上就必須要有完整的規劃,讓你在 40 歲以前可以存到之後一輩子需要的錢。

為了接下來方便舉例,就以我個人為例來回答看看這些問題好了:

  1. 我想進去一間網路公司,因為我喜歡網路快速傳播以及即時的特性
  2. 我想待在一個壓力不要太大但也不能太小的工作環境,壓力太小會讓我覺得無聊,太大會讓我覺得喘不過氣,我不希望找那種可以養老的公司,我需要進步。但我也不希望找每天加班的公司,我覺得這樣的工作環境是有問題的。
  3. 我希望能夠專注在做自己的事情,寫前端就寫前端,寫後端就寫後端,不要找的是前端工程師卻又叫我寫後端。
  4. 我的職涯規劃就是沒有規劃,且戰且走

回答完這些以後,你就有了對於工作的核心價值,這些回答形塑了你想要進去的公司的樣貌,也決定了有哪些因素會讓你考慮進去一間公司。

把上面整理一下,你會發現我想進的公司應該是:

  1. 網路產業相關
  2. 工作 loading 普通,不能太閒也不能太忙
  3. 能夠只專注在一個地方
  4. 沒有升遷制度是 ok 的

職場前輩,就決定是你了!

順利地幫助提問者找出自己對於一份工作的期待以後,接下來就是職場前輩(也就是被提問的我們)可以幫到忙的時候了,還記得上面那些問題嗎?

  1. 以職涯發展來說,大公司的經歷會不會比新創更吃香?至少大公司大家都聽過
  2. 聽說新創做的事情比較雜,會不會到那邊之後什麼都要做,反而比較像打雜的?
  3. 聽說在大公司只能當小螺絲,只負責其中一部分,會不會很無聊?
  4. 聽說人很少的小公司因為培養新人的成本很高,來了就不想放他走,是真的嗎?
  5. 在新創公司如果公司倒掉怎麼辦?
  6. 新創公司的升遷跟獎金制度聽說都不完整,那選大公司是不是比較好?

以提問者一個社會新鮮人的角度來說,他為什麼會問這些問題?因為他不知道嘛,是真的不知道。所以才會用了很多「聽說」,但是實情是不是這樣他也無從得知,因為他根本沒有工作過,所以才會跑來問你。

那誰會知道?就是已經工作過的我們「可能」會知道,儘管不是全部都知道,但至少會比一個社會新鮮人瞭解得多。這就是我認為提問者會來找我的原因,因為我工作過,至少我有在幾間公司待過,所以我能夠回答出上面的問題。這些問題才是我真正可以幫到忙的部分,而我也很樂意回答這些問題。

假設這些問題都被回答了,那現在就有一些事實是提問者能夠參考的,例如說:

  1. 沒錯,大公司的升遷制度通常會比較完整。
  2. 一般來說,新創做的事的確會比較雜,但可以接觸到的層面也越大,可以學習到的面向越廣。相對來說大公司可能就會讓你專注在某一個部分,比較精,但可能接觸到的範圍就沒那麼大。

這邊要注意的是,如果提問者是有具體提出哪一個公司,那當然是最棒的,因為每間公司的狀況都不同嘛!

像我以前也覺得我進了一間五千人的大公司,制度應該跟我想像中的大公司差不多,誰知道進來之後才發現原來我們擁抱新創理念,組織架構比我以前待的新創還新創!有些通則,當然就有些特例,很多東西都是每間公司不一樣的。如果能針對某一間特定公司來回答上述問題,那當然是最棒的。

而有了這些事實可以參考之後,提問者就可以對照剛剛他回答的那些對工作的想像來獲得結論,例如說:

  1. 前提一:我希望能夠只專注在一個地方(這是我想進的公司的第三點)
  2. 前提二:一般來說,新創公司會比較雜,大公司比較專注在一塊(上面回答的第二點)
  3. 結論:以這個因素來說,大公司會是比較好的選項

把每一個因素都這樣比一比,就可以大概得出哪一個比較適合自己。

到這邊為止,其實就差不多可以把原命題「我該選擇大公司還是新創公司」給順利解決掉了。

後記

我覺得原文的回答是針對原問題的其中一個面向,但其實還有更多面向值得我們去思考與回答。就如同我上述說的,在「想成為怎樣的人」跟「該進大公司還是新創公司」之間其實還有一條很大的鴻溝,我們可以試圖把這條鴻溝補起來,就能更明確地、更有幫助地來好好回答這個問題。