美簽：快速簽證之學術面談

五年前申請的美簽即將於今年八月過期，再加上有可能需要到美國出差，所以上個禮拜上網填寫了申請美簽的資料。資料填寫完畢之後，網頁秀出一個畫面，告知「您符合快速簽證服務」（我猜所有曾經獲得美簽又無不良紀錄的人可能都符合此資格），只要將面談時間安排在AM 10:30或PM 12:45便可享有快速簽證服務。沒想到台美關係已經這麼好了（幹的好，馬總統），記得Teddy五年前申請美簽時好像沒有快速簽證服務（這次是我第三次申請美簽，第一次申請後根本沒去美國，白白讓老美賺了簽證費）。既然有快速簽證，當然要享用一下身為台灣人的驕傲。上網查了一下預約的時段，所有下個禮拜AM 10:30 的時段都沒有名額了，因此就預約了7月10日 12:45這個時段。

話說當日11:40從公司搭計程車前往信義路的AIT，12:10就到了。預約的資料上面寫明：「早到者恕難進入」，先天奉公守法的Teddy，不敢提早闖關，所以就不怕死的先去漢堡王吃個快速午餐（大概15分鐘就用吃飽了），乖乖的等到12:45分再去。說也奇怪，Teddy提早了2分鐘到AIT門口，怎麼警衛已經讓人進入，趕快尾隨其他人一起進去。Teddy進去之後才發現，裡面已經有超過三、四十個人在排隊。哇哩勒，那Teddy剛剛在漢堡王是在等假的喔，AIT的資料有點廣告不實的嫌疑。

進去AIT之後，先把手機交給門口的警衛保管（警衛說，你這手機不錯喔…是滴，很識貨，這是有GPS功能智慧型PDA手機），然後經過金屬探測門。我前面有一位先生，還自動解下皮帶才經過金屬探測門（應該是常到美國的熟客，被訓練到自動寬衣解帶，還好沒脫鞋），我心裡就在想，阿又不是要搭飛機去美國，有必要這樣嗎。還好我的皮帶是夜市買的便宜貨，金屬含量不足，順利通過金屬探測門。接下來會有台灣源訊資料處理中心的人先幫申請者把資料檢查一遍，最重要的就是要看看我們有沒有乖乖的先去劃撥簽證費和給台灣源訊資料處理中心的資料處理費。資料檢查完畢之後，先坐在椅子上等待，順便強迫觀賞AIT製作的精美節目，告訴我們接下來要如何的過五關斬六將（最主要是說明掃描指紋的流程，先放左手的四根指頭，再換右手，最後是兩根大拇指），才可以得到一張「上國」恩賜的通行證。大約等不到10分鐘，那個節目也重複看了N遍之後，有一位長的很像海角七號裡面那個「茂伯」的服務人員，把我們帶到另一個房間內，開始正式的申請流程。

正式的申請流程其實只有四關，首先，把資料交給第一個窗口的人掃描。接著，到另一個窗口掃描指紋。第三關有一位留著長髮的小姐（簡稱P小姐）負責看每個人的資料，決定要不要把你叫過去詢問一番。運氣好的人，直接跳到第四關，就是拿回快遞回條（等於美簽通過），可以到快遞櫃檯辦理護照快遞。Teddy辦好前兩關之後，心理正在想這個快速簽證服務真好，等一下就可以離開，說不定還有時間去喝個咖啡什麼的。沒想到，「事情不是笨蛋想的那麼簡單」，不幸的事即將發生。

P小姐：「A先生，請問你是做什麼的」。此時Teddy依稀偷聽到生物…中研院…什麼什麼之類的。P小姐：「你需要到4號窗口面談」。P小姐：「B先生，請問你的學歷是?」。B先生：「博士」。P小姐：「你需要到4號窗口面談」。哇哩勒，就這樣，P小姐叫了三、四個人去4號窗口面談。此時P小姐叫到Kay（PS：Kay是Teddy的同事，當日一起去辦美簽），P小姐：「Kay，請問你是做什麼的」。Kay：「開發軟體的」。P小姐：你是學歷是?」Kay：「碩士」。沒事，過關。此時P小姐叫到Teddy。某驚、某驚，Teddy心想，同一個公司的，Kay都過關了，Teddy應該也沒事。P小姐：「Teddy先生，你和剛剛那位Kay小姐一樣，也是開發軟體的?」Teddy：「死豬」。P小姐：「什麼時候畢業的?」Teddy：「去年10月」。P小姐：你是學歷是?」Teddy：「博速」。P小姐：「你也要到4號窗口面談」。天啊，難道博速也是一種錯誤…就這樣，讓我經歷了前後加起來總時間長達約2.5小時的「快速簽證」。

P小姐一共叫了七、八個人到傳說中的「4號窗口」，奇怪的是，等了好一會，4號窗口一個人也沒有。過了可能有十幾分鐘後，見鬼了，P小姐居然一人分飾二角，又出現在4號窗口，接下來一連串匪夷所思的面談即將展開。我發現被叫去4號窗口的，好像不是學校的教授，就是有博士學歷的人。看了看4號窗口，上面寫著「學術面談」，我…靠…過來一點，Teddy一不進京趕考，二不應徵教職，這個「學術面談」是做什麼東東？難道美國政府要順便看看有沒有好的研究人才，挖角要美國上班? 想太多，接著看下去。

P小姐依據剛剛被她叫到4號窗口的順序，逐一地仔細盤問一番。由於問的內容很細（如果醫院門診醫生的問診時間有P小姐的十分之一病人就要偷笑了），又有七、八個人在等待，現場又沒有提供蘋果日報，整個過程真是無聊到爆。我覺得P小姐好像博士論文的口試委員，又像是系主任正在面試菜鳥助理教授，她問的問題包含了：你的專長、博士論文研究內容、研究方法、應用領域、工作內容、到美國參加什麼研討會、有發表論文嗎、發表幾篇、有無邀請函。至於P小姐問Teddy的問題則是：

P小姐：「你是什麼領域的?」
Teddy：「軟體工程」
P小姐：「你在公司做什麼研究?」
Teddy：「沒做研究，開發軟體，寫程式而已」

(P小姐露出疑惑的表情)

P小姐：「有想要繼續做研究嗎? 」
Teddy：「沒有」
P小姐：「這樣不是很可惜嗎?」
Teddy：「不會啊，我的博士研究是屬於實務的題目，就是要寫程式」
P小姐：「你到美國做什麼?」
Teddy：「總公司在美國，所以要員工準備好美簽，可能隨時要去出差」
P小姐：「所以你們台灣是分公司，要到headquarters 出差?」
Teddy：「對，我們是美商」

(P小姐拿出一張約半張A4大小的紙給我)

P小姐：「請用兩、三個句子寫上你的博士研究內容、應用領域、在公司負責的工作。寫好後再來找我」

後來Teddy發現每個人都被P小姐要求做相同的事。寫完之後再去排隊，我前面那位X先生好像是某科大的教授，P小姐又問了一堆問題，X先生很努力的解釋，順便要展示他真的是正港的教授，不是裝的。後來，很不幸的，X先生和另一位Y先生，都被P小姐要求填寫一張黃色的表格，並且要他們提供一份自己曾經發表過的論文列表、列舉一篇論文代表作（怎麼這些資料和教授升等審查那麼像? 還好沒要求SCI點數超過幾點才可以去美國）、到美國發表論文的摘要、邀請函、行程資料等等，傳真一份給P小姐。此外，P小姐還要他們自己三不五時到某個網址去查詢自己案件處理的狀態，整的流程大概要2~4週。最後還要帶上新、舊護照再跑一趟AIT辦理簽證。X先生和Y先生聽到臉都綠了（現代版的綠面人俑）。輪到Teddy了，我把寫好的考卷交給她。

P小姐：「這是什麼字?」
Teddy：「robustness」

P小姐：「這個字是?」
Teddy：「agile」

P小姐：「你的博士研究是做什麼的?」
Teddy：「就是研究怎麼讓軟體比較不會當機，如果有一個軟體跑三天會當，我們就看看能不能讓它跑五天再當」（友藏內心獨白：結果還不是當，這是哪門子爛研究…）

P小姐：「那你的研究方法是什麼」
Teddy：「就是研究agile methods的例外處理… 就是說，在軟體開發流程裡面，什麼時間點要做什麼事（隨便虎爛一下）」（友藏內心獨白：P小姐以前是審過期刊論文嗎，還是研討會的主持人?）

P小姐：「你去美國要受什麼訓練」
Teddy：「也沒有要受什麼特別的訓練，我們公司是在做主機板的，我在公司開發server management software，公司要求不時都要有人到美國去交流一下」

P小姐：「主機板怎麼拼」
Teddy：「motherboard」

P小姐：「喔，就這樣喔。」

之後P小姐消失約20秒，跟另外一個人討論了一下，回來之後就把快遞回條交給Teddy。（Teddy後面兩個人用羨慕的眼光看著Teddy，這情景就好像金馬獎頒獎典禮中，三個入圍者排排坐，最後宣佈得獎的是…Teddy…）在Teddy前面好像有四個人都被要求要填寫黃色單子，至於Teddy後面還有兩、三個人的遭遇就不得而知了。

此行心得：

(1) 快速簽證猶如馬總統的long stay（攏似假）。
(2) 如果你是博士，又要辦美簽，去美國的目的最好說是「購物」、「要去迪斯奈樂園玩」、或是「祭拜Michael Jackson」也行，就是不要去參與學術活動。
(3) 對付學術面談最好的方法就是不學無術。古人云：「柔弱生之徒，老氏誡剛強」，這話說的一點都沒錯。各位教授、博士們如果研究作的太好，又想跑去老美家裡耀武揚威，老美就算在審論文這一關沒把咱們幹掉，也非得在美簽這一關挖個洞。像Teddy這種無三小路用的博速，既不會危害美國國土安全，也不會像紅火蟻一樣到了美國之後就賴著不走，所以耍個2.5小時也就夠了。
(4) 馬總統，就算你爭取不到訪美免美簽，至少也爭取一下免學術面談吧。

後來回公司之後，在網路上看到一則真人真事。

面試官：「你為什麼要去美國」
面試者：(用台灣國語回答)「因為美國 is very good!」

在不同的Quartz Jobs之中共享資料

Quartz 是一個開放原始碼的排程（scheduling）軟體。要讓Quartz在我們設定好的時間執行特定的工作，首先實作Job 這個介面（interface）。Job介面只有一個方法：

void execute(JobExecutionContext context)

把要作的事情寫在 execute 裡面便可，當設定的時間一到Quartz自然會呼叫你的程式。Quartz的Job是沒有狀態的（stateless），如果你設定你的工作每一分鐘要被執行一次，那麼Quartz每次都會為你的工作產生一份新的instance，執行完畢之後就砍掉。如果希望這個工作每次執行能夠記住上次的狀態，便要實作StatefulJob介面。StatefulJob和Job內容完全相同，都只有一個void execute(JobExecutionContext context) 方法，差別在於Quartz會記住StatefulJob的狀態，也就是說Quartz只會幫實作StatefulJob的物件產生一份instance。例如，你有一個每一分鐘要被執行一次的StatefulJob，Quartz只有在第一次執行這個工作的時候會幫它產生一份instance，執行完畢之後會把該instance留下來等著下次繼續用。

關於stateless與stateful 的優缺點比較到處都有，大家孤狗一下便可。Teddy要說的是，如果兩個不同的Job要互相分享資料，要怎麼辦？看了一下Quartz Job Scheduling Framework: Building Open Source Enterprise Applications這本書，作者很好心的把這個問題留給我們自己思考。經過一翻有計畫的亂試之後，答案著實也很簡單：Quartz 的Scheduler介面，有一個getContext方法，會傳回一個SchedulerContext物件（類似Java的Map），把東西往裡面塞就可以了，所有屬於同一個Scheduler的工作可以看到SchedulerContext裡面的資料。

scheduler. getContext().put(“key”, “value”)

Architect-Builder

▲超級全能住宅改造王，畫面節錄自YouTube

七、八年前當 Teddy 還在念碩士班的時候，在一次專題演講的課程中系上邀請了國內某著名的物件導向大師前來開演，在此稱為 K大師。事隔多年演講的細節早已遺忘，難忘的是，Teddy 從此不需再費心閱讀K大師所出版的雜誌，因為 Teddy 無法認同 K大師的想法。

在演講中，K大師一再強調軟體開發要學習建築業，如此方可做大。在建築業中，大致可分為兩種人，一種是建築師（architect），另一種是承包商（contractor，也可以直接叫做工人）。建築師只負責規劃，不管施工的細節。如此，建築師在畫完設計圖之後就沒他的事了，可以閃人繼續接下一個案子；至於如何將藍圖變成實際的建築物，是所謂的「施工細節」，可以找一堆廉價的工人來施工即可（到哪裡找？中國大陸是當時很熱門的地點）。如果房子蓋不好是工人的問題，絕對不是建築師的問題，而高高在上的建築師也不應該插手這種屬於黑手工作的施工細節，否則將陷於施工細節而無法脫身接其他案子。

這種「按圖施工，保證成功」的想法與做法，還真的有一堆人相信（甚至到現在都還是主流想法）。Teddy 則是奉行敏捷方法（agile methods），多年之後，敏捷方法在 Teddy 心目中已成為一種信仰。不談理論，舉幾個情境說明為何「按圖施工，保證成功」在大多數的情況是行不通的。

（1） 身為一個程式設計師，曾經依據 architect 交給你的設計文件（use cases 或其他輔助的 UML diagrams）不加修改就可以直接做出系統的請舉手？
（2） 身為一個 architect，有能力寫出不需修改便可直接做出系統的設計文件（use cases或其他輔助的 UML diagrams）的請舉手？

Christopher Alexander 認為，要建造一個美麗、有生氣的建築，必須要揚棄傳統的建築流程。Alexander 建議 architects 與 contractors 應該要「金剛合體」，成為一種新的角色稱之為 architect-builder（註一）。這種精神，嗯…看過「全能住宅王」這個日本節目嗎？很像節目中 architects 扮演的角色。在「全能住宅王」中，建築師會事先到委託人的家裡去了解他們的生活背景以及對於住宅的需求，量身打造屬於這個家庭專屬的住宅。在這個過程中，建築師不是畫完設計圖就閃人，而是不時到工地視察，並且經常需要依據現場狀況動態的修改或增加設計。此外，幾乎所有「全能住宅王」的建築師都會自己下海動手設計一、兩件作品，而委託人也會因為建築師貼心的專屬設計而滿懷感謝之意。

Teddy常常聽到有人說 architects 不需要寫程式，甚至有的公司怕 architects 把手弄髒了，還貼心的明文禁止 architects 寫程式。看看 Kent Beck 怎麼說：「If you stop coding, you stop learning. 」

註一：The Production of Houses, chapter 1.

博士論文口試通過

9月25日是我的博士論文口試，結果當然是通過啦。唸了六整年的博士班，一下子畫下句點，當指導教授握著我的手說: "恭喜你，陳博士" 的時候，我卻少了分喜悅，多了分不捨。

說也奇怪，博五之後，心中最大個願望就是畢業，畢竟待在同一個環境太久了，做事越來越沒衝勁。現在口試通過，也找到工作，應該要高興才對，可是心情卻異常的平靜。

不知道其他人拿到博士學位之後的心情是怎樣?

最高興的可能是我指導教授的兩個小孩，因為以後假日我老闆就不用和我一起改論文，可以陪他們玩了。

找到工作了

由於9月25日即將口試，這一陣子花了一點時間在找工作。由於不急著找工作，因此我在104上面輸入自己的資料，被動的等有緣人上門。整個過程一共面試了五家公司。

公司一：某上市電腦公司某某處的一位經理。基本上整個過程是個誤會，面試我的人也沒仔細看過我的履歷就把我找去面試。我對他們的人力需求而言可能 "太超過"了，最後整個面試過程變成我在教他 SCRUM。我心裡在想，"先生，這可是要收費的，你有付我錢嗎。"

公司二：某開發與銷售監控軟、硬體的公司。由他們公司的技術總監跟我面試。這個人看起來是留美的，問的問題都很尖銳。例如，我問他我到他們公司要做什麼，他反問我，我認為我能為他們公司做什麼。我提到可以改善軟體開發流程、導入 software development best practices、還有我可以當任 architect。他當場把他們公司的 DM 拿給我，要我三分鐘之內描述一下他們軟體的架構... 還好平常書看的多，隨便講了不到一分鐘，他就說OK，不用再講下去了。這家公司給的薪水還算滿高的 (比我指導教授在學校領的薪水高.... 這是一定要的啦)，工作也滿有挑戰的，可惜後來因為一件小事沒談妥所以就沒去這家公司了。

公司三：某網路安全與反垃圾郵件的純軟體公司。這次面試我的是公司的技術總監和董事長。自己偷偷高興了一下，因為面試的層級越來越高。該公司的技術總監告訴我，我的自傳寫的很棒，他當場念了一小段 (感動)。就在一切都很順利，即將結束的時候，我告訴他們我期望待遇 。為了測試市場行情，我把第二家公司願意付給我的薪水加了2萬，不過好像嚇到對方。原本他們董事長說要找我吃飯再聊一下，但後來就沒聯絡了，害我難過了一小下子。董事長，薪水是可以商量的啊!

一個禮拜之內面試了三家公司，覺得好累，再加上要準備博士論文口試，就把104上面的履歷表關閉。

公司四：這是認識的人介紹的公司。因為是熟人介紹，所以面試過程基本上沒有問什麼。公司的總經理只問我說，想來我們公司上班嗎? 我回答，可以啊。基本上就這樣。說真的，我要來這家公司做什麼，並不是很清楚，只知道有一個小於10人的軟體開發團隊需要我幫忙帶領。

公司五：原本已經決定去公司四上班了，但有一天他們總經理告訴我，他們老闆對於我的 title 有意見，老闆覺得我是剛畢業的新人 (拜託，我以前工作過六年多耶)， 因此問我願不願意從 XX工程師做起。這有點奇怪，因為我要去協助的那個團隊，裡面有經理等級的人，有那一家公司的制度，是由工程師去管經理的呢?太奇怪了，所以我拒絕了。因此重新打開104的履歷。很幸運的隔天公司五找我去面試。公司五是一家上櫃的純軟體公司，面試我的是他們研發處處長。很巧的是，他7年多前曾經來我工作的公司 demo 過他前一個公司的某種技術 (當場我覺得很不好意思，因為當年我年輕不懂事，對他demo的技術很不以為然，一直給他吐曹)。不過大人有大量，他完全沒有提起。可能是他有點知道我過去的經驗，因此面試的前半場都是他一個人很興奮的在告訴我他們公司在做什麼。後來還是我自己要求要自我介紹一下，否則我看他好像沒打算問我問題。

就在我去公司五面試的隔天，公司四卻又告訴我，原本關於 title 的問題是個誤會，所以還是希望我去他們公司上班 (無言)。

比較這兩家公司：

公司四：硬體公司，起薪比較高，團隊人數 10 以下。
公司五：純軟體公司，起薪比較低，團隊人數可能在 20 ~ N 之間 (因為他希望我除了去幫忙研發之外，還要帶一個 coding center 的 programmers，人數不詳)。

最後選擇了公司四，是因為薪水比較高嗎? 不是。那是因為工作看起來比較輕鬆嗎? 不是。是因為離家比較近嗎，也不是。那倒底是為了什麼? ㄟ ...... 一切盡在不言中。

下禮拜還要趕快跟公司五連絡，告訴他們我的決定。

喝看看就知道

看過維大露P的廣告嗎? 一位外國朋友問蔡振南： "這飲料好喝嗎?" 蔡振南回答："你自己喝看看就知道"。的確，飲料好不好，喝了就知道，再多的言語也無法取代親自嘗試。很多軟體開發的作法 (practices) 也是如此，好不好，動手試了就知道。

這幾個月在幫忙某個軟體開發團隊導入Scrum，經過了好幾個 sprints 之後，我嘗試導入 pair programming (自找麻煩，我知道...)。在苦口婆心說明了 pair programming 的好處之後，原本希望 programmers 可以被我的三寸不爛之舌給說動，可惜用講的效果不彰，沒有人主動採用。後來，我親自下海 (我承認是我偷懶，一開始就應該自己帶頭做)，"趴"在幾個 programmers 身邊一起 pair。這樣試了兩個 sprints，到了第三個 sprint 之後，所有的 programmers 都已經接受了 pair programming。現在幾乎大部分的工作都採用這種方式進行。Pair programming 帶來的效益實在太多，例如：增進學習機會、藉由合作來改善軟體設計、減少加班 (因為太累了，沒體力加班)、趕走瞌睡蟲等等。

同樣的效果也出現在"寫測試"這件事情上面。實施 pair programming 之前，programmers 也被要求 (嚴格講起來是"被期待") 要用 JUnit 寫測試。的確有些人也作的不錯，但是這些由個別 programmer 所寫的測試效果如何，並沒有其他人再加以驗證。實施 pair programming 之後，對於撰寫測試的討論與花在撰寫測試的時間越來越多。此外，由於配對的關係，對於程式碼品質與設計的討論也增多，自然而然地，programmers 也經常利用 refactoring 來改善設計。由於 refactoring 之後需要執行測試案例來確保沒有把原本可以動的軟體弄壞，因此測試的重要性與效益變的越來越高， programmers 也變的越來越喜歡寫測試 (也許還沒到喜歡的地步，但至少意願與動機提高很多)。

我越來越相信，改善軟體開發，幫團隊成員洗腦固然重要，但一定要動手去做。如果要等所有人都認同再動手，有可能永遠都等不到這一天。

在你決定嘗試這些 practices 之前，最好能找到ㄧ個好的 Scrum Master，確保你所嘗試的方向與作法是正確的。我曾經聽說，有團隊宣稱採用 XP 開發一個軟體專案，在過程中曾經花了幾個月的時間在做 refactoring，最後專案以失敗收場。他們得到的結論是，agile methods 不可行。我真的很想問他們："你們確定這是 XP，還是戴著 XP 帽子，但實質上是不知道什麼亂七八糟方法的軟體開發?"

PS: 最近因為三聚氰胺的新聞，赫然發現，飲料還是不能亂喝。

讀書筆記 (別讓員工瞎忙)

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency

Chapter 3:
任務轉換成本 = 轉換的機械成本 + 重複的工作 + 進入狀況的時間 + 挫折代價 (平靜情緒) + 團隊能量的損失

Chapter 5:
為了保持控制權，你必須要放棄控制權。你要儘量少用你的權威，使他人不感覺到你在使用它。你要讓大家感覺控制權是由組織中的眾人分享，而非由你一人來掌握。

你給夏娃和他同事的鬆弛，不是時間上的鬆弛，而是控制上的鬆弛。

Chapter 6:
人力資本 = 完全進入狀況的時間 * (薪資 + 經常費用) * 50%

Chapter 7:
人在時間的壓力之下並不會想的更快

知識工作者應付壓力的方法不外乎：
1. 消除浪費掉的時間
2. 延後處理不在要徑上的任務
3. 晚下班

Chapter 8:
如果進度表訂下的完成日期沒有做到，它就是不好的進度表。這是判斷進度表好壞的唯一標準

Chapter 9:
過度忙碌的主管正在做他們不該做的事

Chapter 15:
知識型工作的作業標準幾乎總是捨本逐末。我見過不告訴你如何產生優質設計 (只管如何撰寫設計報告書) 的設計作業標準、不告訴你如何設計有效測試案例的測試作業標準。這些作業標準等於在說：我將規定你如何執行工作的每一步驟，只除了困難的部份。

Chapter 16:
真正的品質和有無缺陷少有關係，但我們所謂的品質計畫卻只和缺點有關。企業的品質計畫，只不過是消除缺點計畫，如果計畫成功，能讓產品零缺點或將近零缺點。但是這些產品真的有用嗎? 也許是，也許不是，但不管如何，都與品質計畫無關。

Chapter 20:
領導就是號召他人加入陣營的能力。
領導的特質：
1. 明確指出方向
2. 坦白承認短期的痛苦
3. 後續追蹤
4. 後續追蹤
5. 後續追蹤