對於教學的反思

Photo by Tim Stief on Unsplash

做了更長一陣子的教學之後,收穫之一是更能理解以前學生時期碰過的老師,為什麼會有那些行為。我相信有許多人都碰過自己不喜歡的師長,有可能是不喜歡他的態度,或是不喜歡他的教法,而我開始漸漸理解為什麼他們會變成那樣,因為我可能也有一部分正在變成那樣。

但至少,現在的我還沒有 100% 被同化,我可以理解,但不代表我認同。我會盡力讓自己不要變成那樣。

經驗所帶來的認知不對等

身為老師,對自己的教學內容一定是再熟悉不過,會知道自己教了哪些東西,以及哪些東西是重要的。而一個常犯的失誤就是,會一股腦地把自己認為的重點全部都塞進課程。

教學並不是你教了多少,學生就會學多少。它比較像是一個漏斗,就是看轉換率最喜歡用的模型,瀏覽人次是 100 人,可能點了購買按鈕的只剩 10 個,最後購買的只有 1 個。每一個環節都會有所損耗,不太可能來 100 人,就真的 100 人都完成購買。

教學也一樣,我講了 ABCDEFG,學生可能只抓得到 ABCDE,FG 只是聽過有個印象,或搞不好根本忘記有講過,過了兩週,可以只記得 ABC 了。這邊可以改善的地方是:

  1. 該怎麼強調最重要的那幾項?讓學生最記得住?(增加質)
  2. 該怎麼設計教學內容,讓學生能記住的內容更多?(增加量)

而儘管認識到了這點,有時候依然會因為這個不對等而產生情緒。例如說學生跑來問你一個問題,身為老師,你很清楚知道你有在課程上講過,搞不好還特別強調了三次,但學生還是跑來問了。這時候或許會產生一些情緒,心裡想著:「你真的有在上課嗎?我有特別強調過了」

但是對學生來說,本來就不可能記住所有上課的內容,對於那些不知道的內容,不知道就是不知道,雖然說線上課程可以再看一遍,但如果你其實只有其中一小段講到這概念,要找出來還是有一些難度。

我產生過這樣的情緒,但我沒有表現出來。原因是,我確實產生了比較負面的情緒,可是我的理性告訴我,這些情緒對於解決問題,是沒有什麼幫助的。

假設我順著情緒走,跟學生說:「你真的有上課嗎?我課程上都講過了,你再去看一遍吧」,那問題有得到解答嗎?或許有,可能他自己再回去看一遍,真的找到答案;或許沒有,也許他問的東西我只在課程中提了兩句,連我自己都找不到那兩句在哪。

既然這情緒對解決問題沒有幫助,甚至會幫倒忙,那自然也就沒有展現出來的理由。知易行難就是這種感覺吧,你知道情緒沒用,但就是會被情緒牽著走。幸好目前在這個部分我還能控制住,想的不是「我就是想要…」,而是「我該怎麼解決問題」。

不過麻煩的事情是,這個情緒會隨著教學的經驗變多,變得更加嚴重。原因是對我來說,我已經講過這東西五次了,每年都講一次,可是對學生來說,他們都只有聽過一次而已。所以因為這理由而責怪他們是不對的,這只是敗給情緒而已。

若是從解決問題的角度來講,要想的事情是:

  1. 為什麼這問題一再出現?是不是因為課程中沒有讓學生留下深刻的印象
  2. 有沒有方法可以改進?例如說強調這一段,畫三個星星然後說考試會考
  3. 是不是可以準備一個常見問題集,讓學生自己去找答案?

再次重申,說得容易做得難,在當下是會被情緒影響的,需要冷靜一陣子才能依靠理性做事。而這樣的轉換如果沒做好,受到情緒影響時是用忍耐的,那就會令人感到疲憊,倦怠感油然而生。

而且像是「我講過很多遍,但學生還是來問」或是「提醒過很多遍,但學生還是犯錯」的狀況,身為一個工程師,我自已會更無法接受,情緒的反應就更大。理由是,我很討厭同樣的事情做太多遍。就像是相同功能的 function 會抽出來而不是複製貼上一樣,如果有些事情一再發生,就應該找個方法解決掉。

但更麻煩且頭痛的事情是,界線要怎麼抓。白話文就是,當一個學生犯了一個你自認為提醒過的錯誤時,要怎麼知道是你的課程沒做好,還是學生自己沒看清楚課程,沒認真上課?

以前的我說過,我會選擇前者。如果是我課程沒做好,那理所當然要改進,如果是學生沒認真上課,那若是我課程再多加強 10%,可以使他更認真 10%,何樂而不為?我是那種,如果我多做點事可以讓整體結果更好,我就會多做點事情的人。

但前陣子我有想過,這樣真的好嗎?當我多做一點事情的時候,是不是學生就少了一些事情可以做?短期來看結果看似更好了,學生理解了,但如果學生的問題是自己沒認真上課,是不是根本問題還是沒解決。這樣的話,是一種愛之適足以害之嗎?

那在碰到這種狀況時,我該用什麼標準去決定我應該溫柔地回答學生問題,還是嚴厲地斥責,叫他再回去看一遍影片?

我目前還沒有答案。

真的沒有所謂的蠢問題嗎?

通常為了鼓勵學生勇於發問,老師都會說:「同學請盡量發問,沒有問題是多餘的,沒有問題是笨問題,只要你有問題就提出來」,我以前也是這樣的,因為若是有學生提了一個問題而被認定是蠢問題,他以後可能再也不會發問了。

但是,若是看到一些你真的很想稱之為蠢問題的問題,那又該怎麼辦?舉例來說,你可能一分鐘前才講過還說這個很重要,結果一分鐘後就被問了這個問題,這時候情緒就上來了,心底有股聲音告訴你:「這是什麼蠢問題?」,於是就開始懷疑:「真的所有的問題都值得被提出嗎?」

我之前處理的方式跟上面那個段落一樣,我不會表現出來,因為被情緒牽著鼻子走不會讓事情變得更好。假設我真的把這是蠢問題說出口,我可以得到一時間的情緒宣洩,但對於學生來說,他可能之後再也不提問了。所以長期來看,這是一個雙輸的局面。

想解決這個問題,我目前只有想到兩條路。第一條就是克制住情緒,等情緒過了就沒事了,第二條則是開闢一條新的道路,有沒有可能儘管我說這是蠢問題,但不會影響到學生提問的意願?

如果走第二條路,就要先在開始前就跟大家建立好共識,把說詞改成:「同學請勇於發問,有些問題確實是蠢問題,蠢的原因在於它很輕易就可以靠自己找到答案,但你沒有試著去找,或不知道可以這樣找。儘管你覺得某個問題很蠢,你還是應該要提出來,因為如果你沒提出來,你就不會知道答案」

我相信有些老師確實抱持著「沒有問題是蠢問題」這個心態,但同時我也相信學生應該很多人根本不認同「沒有問題是蠢問題」這個命題。如果是這樣的話,那是不是一開始就跟大家一起承認其實有蠢問題的存在比較好?先承認它存在,再去進一步講述為什麼蠢問題還是應該要提出來,而不是悶在心裡。

又或者,這其實是一個匿名提問機制就可以解決的事?如果沒人知道是你問的蠢問題,那是不是大家就都敢提問了?

或說不定可以有一個每天提問次數的上限,一天就是三次,不能累積,今天沒問完的扣打就沒了。而這個提問次數的限制其實用意正好相反,並不是為了「限制學生問問題」,而是透過次數的限制,吸引學生去問問題,大概就像是「再點 50 塊的東西就可以折 40 塊欸」的那種心態,你本來沒有想吃這麼多的,但看到優惠就忍不住了,想說不賺白不賺。

教學方向的選擇

教學有很多種路線,很多個方向。

例如說可以擔任資源的媒合者,自己不下去教學,幫學生找厲害的老師來講課,找想要徵才的企業,把資源都拉在一起,讓學生享受到很多資源。

也可以不走手把手教學,而是出一堆作業跟小專案,提供給學生大方向跟指導,其他學習的資源就讓學生自己去找。

還有一種是不可或缺的角色,就是真的手把手下去教的,從零開始一步步教,讓學生把基礎打好,真的學會這個技能。大多數的線上課程都可以算是這種。

我想做的一直都是這一種。我不想成為名字會出現在北車補習班招牌上的那種人,要拿這個做比喻的話,我想成為地方的小補習班裡面其中一位老師,學生人數少,但卻印象深刻。

總而言之,我想站在第一線去面對學生,而我也一直這樣做,直到最近開始有了些改變。

以程式導師實驗計畫來說,第一期大概 10 幾個人,第二期可能 30 個左右,但是到最近的第五期,就變成了 70 幾個人,而為了應付這樣的人數成長,我找了助教來改作業,所以作業都交給了助教(基本上都是以前的學生)來改,而學生有問題時也會比較頃向先問助教。

有些人可能會說:「這樣不是很好嗎?這樣不是就可以規模化了嗎?」,不,這樣不好。不是每個人都想把這個當成企業在做,不是每個人都想規模化,至少我就不是。

所以對我來說,我比較晚才意識到助教制度帶來的不全然只有好處。

有了助教以後我不用改作業了,而且助教還改得比我認真比我好,我也不需要一直回答問題了,有助教可以問,但如果把這些都拔掉之後,我還剩下什麼參與在課程中?只有那些錄好的教學影片嗎?

但其實這並不是助教制度的問題,而是我的問題。就算有助教改作業,難道我就不能再把作業看一遍嗎?我就不能自己多參與一些學生間的社群活動嗎?是我自己把自己限制住,或這樣講好了,是我的惰性使然。已經有人改作業了,懶惰的我怎麼會再看一次呢?

以前我在拖延症的文章中寫過,我需要一些事情來推動我,如今我自己把這些事情給處理掉了,就沒有東西推動我了。解法有兩個,第一個是把助教制度砍掉,回歸成我自己處理一切事務,第二個則是要找到並存的方式,既有助教制度,又能夠推動我自己。

上述是前陣子累積的一些有關於教學的心得。趁著自己還記得時趕緊寫下來,否則過一陣子又會忘記了。

這篇教學的心得跟以往滿不一樣的,以前比較多的是針對教學內容的心得,這次比較多是心態面的東西,這一次的教學中我自己的心態確實跟以往有點不太一樣,但確切原因我也還不知道。

不過我相信只要能冷靜下來抱持著初心,以「解決問題為最優先」的態度去思考,應該就不會走得太偏。

「教學」的其中一種解釋是,兩個動詞指的都是老師而非學生,老師除了教以外,其實也在學,學著怎麼教學。

重度拖延症患者,興趣是光想不做,有很多想做的事,卻一件都沒有執行。無聊的時候喜歡寫文章,發現自己好像有把事情講得比其他人清楚的能力。相信分享與交流可以讓世界更美好。Medium 文章列表請參考:https://aszx87410.github.io/blog/medium