工作達人(Job Da Ren)
服務是我架站的宗旨

在讀完你絕對不應該做的事 之一之後，ㄚ琪要繼續讀揭露冰山般的秘密，這一篇寫得太寫實，ㄚ琪之前在工作室的時候，碰到的客戶真的就是如此，程式設計師不曉得經理人想什麼，經理人不曉得程式設計師在做什麼，今天讀完這篇之後，我想他們都會清楚了吧！知道這之間的秘密，不知還能不能有高薪的可能？

『在這些客製化的案子中如果出現進度延誤、失敗或各種災難，都有一個最常見的原因。這個原由基本上可以濃縮下面這句話：「客戶(應該說多餘的客戶)並不知道他們要的是什麼？」』這的確是事實，我的某行業的第一個客戶很清楚知道要做什麼，之後，這個行業的第二個客戶竟然是因為看了第一個客戶的程式（我寫的）而找上了我，可以想見的是，第二個客戶是不太知道要做什麼的。

下面這個件事：『客戶不知道他們要什麼。別再期望客戶知道他們要什麼。這種事就是從來沒發生過，你就認了吧。』有時明知是這樣，還是會犯錯，看來大家的記憶太好了！

『代替的作法是假設你反正都得做出一些東西，而客戶也得喜歡你做的東西，最多只是會有點驚訝而已。你得自己去研究，自己去找出一個設計，能皆大歡喜地解決客戶的問題。』這一句我覺得有深奧，因為看起來這不是程式設計師的工作了，應該是SA的工作吧！程式設計師美其名有個設計兩字，但是我想應該很難自己可以找出一個設計解決客戶的問題吧，特別是客戶還不知道問題是什麼的時候。

讓人很震驚的秘密來了。

『重要推論一：把使用介面的畫面展示給非程式人員看時，如果這個介面很不好，對方會認為你整個程式也是很不好的。

重要的推論二：把使用介面的畫面展示給非程式人員看時，如果這個介面非常漂亮，對方會認為這個程式幾乎已經完工。

重要的推論三：同樣是網路公司，比起功能齊全又累積了3700年資料但用灰色底色的網站，只有四個網頁但外觀漂亮的會獲到較高的評價。

重要推論四：因為政治因素要求由各技術經理或客戶「啟動」專案時，可以提供數種美術設計讓他們選擇。

重要的推論五：展示時唯一重要的就是畫面。一定要讓它美得冒泡。』

我的客戶全犯上這些問題，你能不注意到嗎？我注意到了，只是我沒像約耳說出這樣頭頭是道。

『

要知道在暗室裡用投影機所做的任何展示都只是像素而已。如果可以的話應該把未完成的使用介面畫得像未完成。舉例來說，在功能完成之前對應的工具欄圖示就只用草圖。如果是建立web服務，在功能完成之前就先不要放在首頁裡。這樣大家就會逐漸看到首頁由三個命令擴充到廿個命令。

更重要的是要確定你控制了大家對時程的想法。提供一份Excel格式的詳細時程。每星期都送出自我慶祝的電子郵件，談論本週進度如何由32%進步到35%完成，可以如期在十二月廿五日發行。不要讓專案是否正常進行的想法影響到真正的事實。

』

上述作法可以好好利用喔！ㄚ琪覺得有些時候拿作品去面試，不太成功就覺得可能是展示沒有讓它美得冒泡。戒之…但是ㄚ琪並沒有很好的美術能力，唉！很為難！

在讀完人的工作切換有害無益之後，ㄚ琪要繼續讀你絕對不應該做的事 之一，你相信嗎？這一篇所說的事情ㄚ琪以前都犯過喔！來吧！看看我怎麼說。

『Netscape 做了一個每家軟體公司都可能犯的一個最糟的策略錯誤：他們決定把程式從頭重寫過。』

『程式師總想把舊程式丟掉重新開始，其中的原因很微妙。他們會認為舊的程式是一團亂，不過下面這有趣的觀察指出他們可能是錯的。他們會認為舊程式一團亂的直正原因是一個很基本的程式設計原理：

讀程式比寫程式困難。』這個原理再簡單也不過了，想起以前在365的時候，那是一個亂糟糟的工作場合，很多程式都是由很多前人完成的，ㄚ琪覺得讀程式確實很麻煩，所以很多時間，都會直說重寫比較快，哈哈，還好老闆也不懂，有時確實會順的我意來做，真沒想到，今天碰到約耳說到我的死穴了，好吧，我知道我要悔改了！

『幾乎每一個人都會告訴你：「這真是一團亂，我真想把它丟掉重新開始。」』這句話那時我用得可多了。

至於我們會說一團亂了原因，約耳分析的滿中肯的，『首先是架構上的問題。』我想約耳對這個建議很清楚，就不多說了，這個原因確實可以克服的！

『第二個原因是效率不好』，其實就是改寫效率不好的程式不就得了，身為老闆或經理人可得學起來喔，免得被程式設計師騙了。

『第三個理由是說程式碼他X的醜。』這是粗俗語，ㄚ琪應該沒用過，哈哈，戒之囉！

『一些回饋意見 ，包括某位很資深的前Netscape工程師的回應。另外Seth Gordon寫了一封電郵給我，針對閱讀他人的原始碼提供一些很好的技巧。』

這裡面還有一個角度沒提到，在工作室的時候，很多客戶的舊軟體廠商不見了，客戶苦於功能欠佳或是有問題，想找我改進，雖然我很想把他們的舊程式拿出來改，可是沒辦法，因為廠商都只會給執行檔，不給原始碼，這種情況下，我只好兩手攤開說要重寫了，這是重寫的一個很好理由吧！這種情形碰到的機率還滿大的，後來ㄚ琪幫客戶重寫程式後，客戶也聰明了，要我留原始碼，哈哈，這有什麼問題，我很樂意啊！只要後來接這些程式碼的工程師，不要說我的程式一團亂，願意改寫，那就真的太好了，哈阿哈哈！

在讀完不用測試人員的五大(錯誤)藉口之後，ㄚ琪要繼續讀人的工作切換有害無益，但是其實ㄚ琪並不全然覺得這篇寫的完全都對，有些感覺還是有欠缺的地方，不過先看下去，看我腦中能不能浮現出哪裡不對勁？

『在管理一個程式團隊時，第一件要學的事就是任務配置(task allocation)要正確。』這是個我覺得沒什麼問題的原則。

『工作切換用的時間愈長，多工處理的代價愈大。』這個基本上沒什麼意見，但是如果以人的立場來看，還是有點怪怪的，首先人的工作不可能過長，超過一段時間之後，人的效能會因疲倦，及其它某種我說不出的原因而變慢，因為約耳只是提到多個工作之間的切換，所以我覺沒什麼不妥，但是如果只有單一工作，而人的生活中還有其它時間需要配置的話，顯然這化就有點不合理。

再者，有時深陷在單一工作，也還是有問題，當然這是指工作不順利，有障礙的時候，此時我覺得跳脫到另一個工作，暫時忘記這件工作，或許會有益處。當然當在跳回這個工作時，確實需要花時間再回復記憶之類的，姑且稱之為前置時間吧，但有時重想確實會有不同的結果會產生，夠神奇吧！

『事實上這一切的重點就是絕對不要讓人同時做一件以上的事。請確定你有明白它的意思。好的經理人會認為自己的責任是消除障礙，好讓大家都能專注在一件事情並把它真的完成。遇到緊急狀況時，請先想想能不能自己處理掉，真的不行再丟給深陷在專案中的程式師吧。』這一篇文的原則，沒什麼大問題，小意見我已加註，就讓我們把生產力加增吧！

好吧！看到這裡，我想我的CHM檔格式的問題，不宜拖太久，現在搞不好都忘記得重頭再來了，當然我知道自己是碰到障礙才跳到別的工作的，但是也是該回CHM檔解析的工作上了！

在讀完激勵有害之後，ㄚ琪要繼續讀不用測試人員的五大(錯誤)藉口，ㄚ琪先自評會犯哪些錯誤客戶會替我測試軟體跟我請不起測試人員，原來我犯了最笨的錯誤，唉！沒錢要開一人公司，怎請得起測試人員啊！又抱怨了一次…

一個重點原則『直接算人頭每兩個全職程式師請一個全職測試人員就對了。』這個比例看起來測試部門要很多人說。

再仔細看一下五大藉口吧：

1. 問題是懶惰的程式師弄出來的。

2. 我的軟體放在網路上。即使有問題也馬上就能修好。

3. 客戶會替我測試軟體。

其實開一人公司的老闆應該都很想這麼做吧，就像Netscape的測試方法一樣，但是竟然下場這麼慘，好吧，想辦法再搞半個人來吧！去哪找？

4. 有資格可以勝任的人都不想做測試人員。

但是真的就連我也不想幹測試人員，不過呢？人各有志我不可以偏概全，如果還是有人願意走這一行的，可以繼續看約耳的留人建議：

把測試當作技術支援的下一個晉升工作。
允許測試人員上程式設計課程拓展職業生涯，並且鼓勵較聰明的測試人員，運用程式工具及腳本語言開發自動化測試套件。
要有頂尖測試人員經常流動的認知。
找尋「非傳統」的工作者：找聰明的青少年，大學裡的小朋友還有退休人士來兼差。
雇用臨時人力。

下面這種方法無法處理這個問題：

• 1. 千萬不要對來工作的電腦科系學生打歪主意，說什麼「所有人都要在QA部門磨練一陣子才能去寫程式。」

5. 我請不起測試人員！

看來最笨的人要懂得反省，這樣經濟成本的算法才會比較真實。

在讀完軟體人員面試教戰守則之後，ㄚ琪要繼續讀激勵有害， 什麼？激勵是有害的？看來很shock的，從來就沒聽說過獎勵人心會有害的，約耳說『微軟的「出貨」獎曾讓雇員們覺得自己被當成小朋友。到處都是不滿的噓聲』，這個故事在Douglas Coupland的經典作品Microserfs（微軟奴隸）中裡面有一群程式師嘗試用一根吹管把它破壞掉有提到。

我想我所處公司績效系統也是來自呆伯特式管理書籍上來的，跟約耳講得差不多，很多獎勵方案既侮辱又貶低人，Maybe吧！『績效評估對士氣的作用並不是對稱的：負面評價對士氣傷害很大，可是正面評價並不會改善士氣或生產力。』『巴伐洛夫制約實驗中的狗為獎賞而工作』是我喜歡看的實驗，哈哈！績效評估的困難『在於大多數人都認為自己把事情做得很好(即使事實上不是)。這其實是我們心裡為了讓生活不那麼難受，而對自己玩的一個小把戲。所以說如果每個人都覺得自己表現良好，而評估結果正好是公正不阿(這並不太容易做到)時，那麼大多數人都會對評估結果感到失望。』這還說得真貼切，拿捏得度確實不簡單，『團隊中誠實地實施績效評估通常會導致士氣低落或憂鬱，甚至會有部份人員離職，影響長達一星期左右。團隊成員間會產生間隙，通常是因為考績差的人嫉妒考績好的，發生如同DeMarco 和Lister稱之為團隊殺手(teamicide)的過程：已凍結的團隊不自覺的毀滅。』，原譯是翻成團隊自殺，但我看這一章的中譯叫團隊殺手，我覺得可能比較適合大家。

Alfie Kohn在哈佛商業評論中一篇已成為經典的文章中寫道：

『過去三十年間至少有兩打以上的研究明確地指出，為了報酬而工作的人，表現不如完全不期望有報酬的人。HBR Sept/Oct 93』

他的結論是「激勵(或者說賄賂)在職場上是行不通的」。

『DeMarco和Lister更進一步明白地表示，任何型式的職場競爭及獎懲方案，包括以前流行那種「在某人做對事時馬上獎勵」的把戲，所帶來的傷害都大過好處。給某些人正面激勵 (比如愚蠢的公開頒獎儀式)暗示他們其實只是為了拿那個壓克力獎牌才有表現；也暗示他們在工作上不夠獨立，要有甜頭才會努力；這實在是既侮辱又貶低人格。』

看起來好像績效評估系統很鳥，我大概知道的是績效評估系統可能確實是做做樣子，但是那些來自人力資源部門的同仁也得找事做啊，搞了套績效評估系統，算是他們的績效吧，結果評估這些科學家這類的員工（或許我也可以自詡為科學家），那這個評估系統，還真有點搞屁的感覺，好了，不可以批評的太大聲，不然會失業的，記取『不要惹腦小老闆』，因為我們以後還是要靠他吃飯，做做樣子就好，那生活會過得很快樂！

在讀完由使用者端自動取得當機回報之後，ㄚ琪要繼續讀軟體人員面試教戰守則，但是如果你到原文看，你會看到『This is a very old version of an article that has since been extensively rewritten. The latest version is The Guerrilla Guide to Interviewing, Version 3.0.This version is here for historical reasons only.』這樣的建議，好在新的一篇也翻譯好了，軟體人員面試教戰守則(第三版)，所以ㄚ琪一文看四遍，看有沒什麼啟發？

這一篇管理開發人員的面試原則，但是相反地，你也可以把它當成，如何被錄取的原則，如果你的志願是開發人員的話，所以我們可以從這兩個角度來看，一個是如何面試人，一個是如何被錄取。約耳分析說有三種人：一種人是混的人，缺乏最基本的工作技巧、一種人是才華橫溢的超級明星（哼，約耳自屁為這類人，好吧！先姑且認同一下，ㄚ琪還是謙虛一點好了），大多數的人是不能確定水平的候選者，如果捫心自問，ㄚ琪可能被列為這一級的，所以說，要怎樣在面試過程中，從這個層級邁向才華洋溢的超級明星，就很應該好好地讀讀，因為不只約耳要找明星，所有的公司都想找到這樣的明星。

約耳的錄取標準：『有頭腦，並且能完成工作 (Smart, and Gets Things Done.)』，確保你對問題的解決沒問題，如果你常碰到挫折，現在還能存活，表示你的問題解決能力夠強，相信很多人都會喜歡，ㄚ琪也很喜歡！有頭腦不是那種看起來有頭腦但是不能完成工作的人雖然那種人經常擁有博士學位，所以請公司覺醒吧！不是只有博士才有頭腦的，碩士生也有啊，像我只是沒時間再去念博士而已！至於那些完成工作但是沒有頭腦的人是公司的累贅，是負債，講得可真露骨啊！

約耳面試時最重要的法則是：

『做決定 (Make A Decision)』

所以若是你常猶豫不決，請你千萬不要幹經理人，這樣你會很難找到明星，那些明星在你那也很快幹不下去，對於一個這樣個性的人來說，你的生活要常常面臨忍耐的考驗，希望你可以適應愉快！

「錄取你，但是不能在我的團隊中」「也許，我不確定」「嗯，錄取，我想是這樣的。但是關於…，我想知道…」這種話請不要是擔任面試官的你要講的，切忌啊！雖然如果公司體質不佳的話，很怕找不到明星，這樣根本沒人來做，但是換各方向想想，縱使找到這樣一個普龍共的，你公司還是不會有起色，但是如果真的找到千里馬的話，那公司就有艾科卡來幫你反敗為勝了，所以呢？如果你真的是明星，那你去哪家公司，好像就沒有差別了，但是如果你是中間人是，我會勸你不要去那種公司，因為你會害了他們！倒不如找個體質好的公司，這樣子幸運的話，或許可以進去餬口飯吃！反正公司好，不會倒！

「Oracle 8i中的資料類型varchar和varchar2有什麼區別」這種差勁的問題，準上班族就不用準備了，反正這個未來的老闆，也不怎樣！

看一下約耳的面試計畫：

1. 自我介紹
2. 應試者參加過的專案
3. 無法回答的問題
4. C語言函數
5. 你滿意嗎？
6. 設計問題
7. 挑戰
8. 你還有什麼問題？

面試者要盡量讓應試者放輕鬆，這種老闆真體貼啊！真要好好觀察了，如果我有這個機會再去應試的話，喔！不，我希望可以一直在我這家公司混口飯吃，所以這招，還是給畢業生注意好了，我可是要好好學學這個面試原則的人啊！

我想討論專案，應該是件滿能勝任的吧，ㄚ琪有類神經網路的學校專題，也有資料探勘的論文，也有可以讓部門的生產效率提昇的資訊專案，來錄取我吧！哈哈～！但是要從這裡找得其實是『熱情』，注意了，這個態度真的很重要，我在教會也用積極來看你喔，因為這可以套在工作職場上，所以或許你可以不用談專案，談你有沒信仰，是否積極應該也可看出！

『無法回答的問題』好像是腦筋急轉彎，好吧！大家不要被嚇壞了，就找個依據隨掰掰吧！

程式問題：

1. 1. 將一個字串逆序
   2. 將一個鏈表(linked list)逆序
   3. 計算一個位元組(byte)裏有多少bit被設成on
   4. 二元搜索
   5. 在一個字串中找到可能的最長的子字串，該字串是由同一字元組成的
   6. 字串轉換成整數
   7. 整數轉換成字串 (這個問題很不錯，因為應試者要用到堆疊或者strrev函數)

糟糕，ㄚ琪太久沒寫程式了，這些問題有點生疏了說，那我一定要好好複習想想才行，請大家等著，我一定會幫各位做面試前複習題的，敬請期待！

他們的函數運行快嗎？看一下他們多少此調用了strlen函數。我曾經看到應試者寫的strrev的演算法竟然只有O(n^2) 的效率，而標準的演算法效率應該是O(n)，效率如此底下的原因是因為他們在迴圈中一次又一次調用strlen函數。

『Is their function fast? Look at how many times they call strlen. I’ve seen O(n^2) algorithms for strrev when it should be O(n), because they are calling strlen again and again in a loop.』

當我看到這句中譯時，讀來有點問題，所以把原文貼出，中譯有說竟然只有O(n^2) 的效率，有時候我覺得令人驚訝的語氣，可能是很厲害的，雖然這裡看起來是很鄙視的一種語氣，效率如此底下的原因應該是注音錯別字，可是原文沒有這樣說喔！原文只說因為他們在迴圈中一次又一次地呼叫strlen，這個典故可以查回歸原點得知！

『許多人注定腦子裏就沒有理解指標的那根弦。所以說理解指標是一種與生俱來的品質，而不是一種單純的技巧。理解指標需要腦子轉好幾個彎，某些人天生不擅長轉這幾個彎。』確實我發現指標挺難的說，要搞清楚真的得花很多時間，不過一定要會，不然你沒法通過像約耳這樣的面試！

『計算一個位元組(byte)裏有多少bit被設成on這個問題，是考考面試者對C的位元運算的掌握，但這是一種技巧，不是一種品質，所以你可以幫助他們』，什麼查表演算法、緩衝機制以及最聰明聰明的演算法，大家要掌握，怎麼做？現在我不知道！

有些面試寫作技巧：

事先向應試者說明，你完全理解，沒有一個好的編輯器光在紙上寫程式碼是困難的，所以你不在乎他們手寫的程式碼是否看上去不整潔。

好程式設計師的標誌：這個應該大家都懂吧，不多說，不過ㄚ琪有這個好習慣！

好的程式設計師在寫程式碼前會訂一個計劃，特別是當他們的程式碼用到了指標時。畫草圖是一定要的啦，ㄚ琪沒這麼高招，所以碰到較難的題目一定要畫圖看看！

問『你對程式碼滿意嗎？』這個問題，對ㄚ琪來說是覺得較困難，因為我覺得這有一些盲點，寫好了的程式一般通常很難說出它有缺點，既然沒缺點，應該會很滿意吧！所以說…問這種問題就好像在打心理戰一樣，玩梭哈好像也是這樣，不是嗎？

第六部分：關於設計的問題。就像是要徹底地瞭解使用者需求，才能設計出東西來是一樣的道理，那個只『畫了一個方塊』的面試者，來人啊！拖出去了吧～！

第七部分，挑戰，都到最後了，不管怎麼玩都要堅持下去，別被面試官唬了，錄取即將在望！

負面的面試問題：

首先，避免不合法的問題。有關種族，宗教，性別，出生國，年齡，服役記錄，是否老兵，性傾向，生理障礙的問題都是不合法的。

其次，不要在問題中給予應試者暗示，我們公司喜歡或者不喜歡什麼樣的員工。

最後，不要問那些腦筋急轉彎的題目，例如6根火柴怎麼拼出4個三角形。希望我可找到不考這種題目的公司，很多公司就是喜歡這樣考，切！

第三版的面談，另外題到了履歷篩選和電話篩選，這兩個環節是面談之前的過程。

寫程式來測驗面試者還是很重要，但是這一版的問題變成了：

1. 寫個函數找出某個字串是否以大寫字母A-Z開始
2. 寫個函數算出半徑已知的圓面積
3. 將某陣列中所有的值累加起來

這裡改用簡單的問題來測試，不過測的是速度，哇，不是會了就好了，還得熟練啊，這個測試更艱深了不是嗎？我想這時候我有點汗顏我還能繼續帶在軟體界了。

遞迴和指標的問題，還是不會變，經典問題，超永恆的！如今很多原本的名校可能都只用Java了，看來約耳是覺得不以為然了，我也有點是，不過我還是要準備SCJP啊！

『向應徵者推銷這家公司和這個工作。即使你不想錄用對方，這一點還是很重要。』但是我覺得面試官總是拿這個來考應試者，你好像應該要對公司有瞭解吧！很少聽到考官會好好推銷的！

『決定是否錄取應徵者最佳的時點，是在面試結束後約三分鐘加右。太多太多公司允許面試官在幾天甚至幾週後才交出意見。問題是時間過得愈久，記得的內容就愈少。』看起來這個有效率多了，我的面試經驗是都要等一週以上，因此Yahoo的第二次面試，我沒去了，我等太久了，去別家公司上班了，唉！

第三版感覺補充了很多較新的資料或者是闕漏的，但是主旨沒啥改變，所以我很快地瀏覽過，分享給大家看看！裡頭有些問題，我看是須要好好研究複習一下，培訓一下未來的面試可能。