來了之後我覺得收穫最大的,就是資格考的準備課程,一般 CS 學生大概不覺得考試有什麼困難,我在台大更是第一個學期就考完了資格考 (離散/線代/OS/Archi/Algo/DS)。但是因為我念的 Software Engineering program 隸屬 Informatics department 底下,這整個 department 都怪怪的…嗯我是說這是一個跨領域的學門,即使是軟體工程,也特別偏重 human factor, human computer interaction, social impact 等與社會科學較相關的因素,所以我們的資格考不考 CS 專業科目,相反的,你必須用六個小時回答四道情境或申論題,然後在答案裡展現出你在整個軟體工程領域的學術與實務知識,考試結果有 PhD Pass, Master Pass 與 Fail 三種,教授們對於 PhD Pass 的答案更是有高度的期待,你必須呈現出你的抽象思考與解題框架,只引用參考文獻裡面的知識是不夠的。這是什麼意思呢?假設你要回答以下問題:

你負責規劃開發一個醫療資訊系統,而在軟體開發實務中有所謂的 A 流程/技術與 B 流程/技術,你覺得以這個系統來說,採用 A 或 B 那個比較好?為什麼?

身為一個工程師,我們解決問題的流程通常如下:

  1. 大概了解要解決什麼問題,需要什麼核心功能
  2. 直接 google 網路上最常見的解法,找最多人使用/文件最齊全的技術或工具
  3. 直接把找到的解法套下去用,看看效果如何
  4. 問題不一定要完全解決,只要使用者/利害關係人沒意見,就可以結案。然後接著處理下一個問題,因為現實世界中要解決的問題不只這一個。

好了,套用工程師思維,我很可能會先描述一下我對這個系統的假設,再依我對 A/B 流程或技術的實務經驗或相關論文的理解,選擇其中一個,並說明選擇的理由,為什麼我的選擇比較好,大概幾百字或頂多一頁 A4 就可以答完了。

這個理所當然的回答,大概只能得個 Master Pass.

真正有病的…嗯我是說真正完整的回答,不能只回答問題本身,你要回答的,是問題背後的問題。比如說:

什麼叫做”好”?在你假設的系統需求下,好的定義是什麼?它有可能改變嗎? A/B 流程或技術的步驟或核心是什麼?是它們的哪一個環節比較符合你對於好的定義?就算你選擇了其中一個,另外一個在什麼情況下會比較好?甚至,要符合你所定義的好,採用哪個流程/技術根本不是重點,重點在其他地方?

看出來了嗎?你必須小題大作,題目要你選邊站,但你不能真的只選一邊,你必須要兼顧到兩邊,甚至有可能選哪一邊根本不是重點。所以首先你要把題目不清楚的地方都做好假設,接著拆解問題中專有名詞的概念,架構你答題的框架,最後把問題放入你的框架中回答,過程中參考文獻不是拿來答題用的,你必須先有自己的論點,然後引用文獻支持你的論點。這沒有個兩千字是寫不完的。

如果是在公司或與人口頭溝通時搬出這套,大概就直接被轟出門了,工程師思維的我內心的 OS 也是:誰有空聽你在那邊嘴這麼多?我甚至覺得雖然這跟寫論文所需的 critical thinking 有關,但很多時候論文只是起源於一個待解的問題,把解法想出來,related work, motivation 跟 evaluation 補一補就寫好了,要嘴到這樣也太走火入魔了吧!但是,我從一開始的不以為然,慢慢地也學著接受這個考驗,除了考試就是這麼現實以外,同時它也是一種思考訓練,最重要的是,它是訓練我運用文字跟嘴砲的好機會,因為從古希臘以降的西方哲學告訴我們,這個世界就是嘴出來的,你雖然不屑,但你會發現:你想嘴的時候還嘴不出來,因為你念的書不夠多

這對我來說比考數學或專業科目難多了,根本是知識累積跟英文寫作的雙重難題,但我很樂意接受這個挑戰,畢竟這就是我來的目的。