l

2008年9月27日 星期六

博士論文口試通過

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

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

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

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

2008年9月21日 星期日

找到工作了

由於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,人數不詳)。

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

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

2008年9月12日 星期五

喝看看就知道

看過維大露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: 最近因為三聚氰胺的新聞,赫然發現,飲料還是不能亂喝。