經驗妨礙進步

前陣子機緣得見一位科技業前輩，某 IC design house 創辦人，主要是希望能知道他對我們公司的看法，可能的話願意投資當然也非常好。他對技術仍然很有興趣，談吐也不脫研發氣息，反應快，印象很深。會間提及之前由於合作的中國公司堅持使用自有機房而非雲服務，導致我們對 virtualization 提早投入，用以配合數台實體伺服器動態調整。如果可使用某種 IaaS，當時其實還不到發展時機，對資源確實有些浪費。但這位前輩，似乎高估了需投入的資源，而實際上由於我們完全採用 open source solution，不論在金錢或人力方面投入都並沒想像的高。

Open source 此言一出，觸動他某些回憶。晶片廠做軟硬體整合的流程，從 Openmoko 到 0xlab 一路下來，會有些什麼問題其實知之甚詳，所以對他分享的經驗蠻能理解，感同身受。但由此經驗推測到我們使用 open source（其實也就是 Docker 之類，無甚稀奇）也會碰到類似問題，就不盡正確了。兩者情境不同，在軟硬體整合時，必須緊緊追蹤上游發展，掌握架構，實際「參與開發」上游專案，不論在研發與社群參與都要投入，才能做得好。但我們的案例，是在 DevOps 這個層次將各種軟體元件組合起來，重點是對各元件的特性、功能、缺陷正確理解，會碰到的問題多半是流程與架構方面的，與是不是用 open source 關係不大。

雖然再三嘗試解釋，但顯然由於我的笨拙，以及這位前輩對自身經驗的信心，所以感受得到並未被說服。如前所述，對前輩是很尊敬的，在如此人物身上也有這問題，平庸如我輩者自然更需戒慎恐懼。年紀越長，自然越仰賴經驗，畢竟世間道理，往往親身經歷一次，才體會最深、得益最多。然而資訊科技瞬息萬變，領域又如此廣闊，即便是曾經涉足的專業，離開一陣子很容易就脫節，過往經驗，未必適用。

要說如何避免，也是老生常談。不脫避免先入為主、勿妄下結論、保持虛心、時時學習等等。然而老生常談之所以成為老生常談，也就是因為太多人明知如此，實際卻沒做到。大千世界，無處不是學問，慎之。

十年職涯

算起來是 2003 開始做事的，到了去年 2013，十年了。這陣子碰到一些事情，結合起來有感而發，想寫寫東西，對這段歲月做個小結。

以前系上學的，偏重資訊系統（MIS），算是應用領域，接觸的多半是系統分析、Java 之類的技術，在 Windows 上面用 Visual Studio、Eclipse 之類的 IDE 寫程式。但第一次面試，就碰到蠻喜歡的主管，風馬牛不相及的跑去了嵌入式 Linux 領域。初接觸整個 Linux 世界，立刻就喜歡上那種「一切都有程式碼可以看」的感覺，從學著同事用 VMware 裝 Linux 然後用 Samba 開放出檔案，然後還是在 Windows 下用 UltraEdit 作業，到自己覺得要學就學整套，把筆電改灌 RedHat 7.2（那時候還沒有 Ubuntu，周遭則是沒人用 Debian）。記得有天問同事，在 Linux 底下哪套 editor 寫程式最好？記得他想了想，說看過評價是 Emacs 好，但他自己沒用過，所以不確定。就這麼一句話，開始我十年的 Emacs 坑。

部門後來從母公司切出，獨立出來一間新公司 QNAP（是的，就是後來上市發大財那間），環境較小，很快就覺得有些東西學不到。這時從其他公司挖角來的新同事建議，去他原先任職的公司 TrendMicro 長些見識，並幫忙找了介紹人。雖然 QNAP 已將我升遷為經理，但思來想去，仍然覺得成長比較重要。過去一看，的確制度好很多，也有很多高手。說來慚愧，當時對嵌入式系統的理解，竟然覺得重點就只是 cross compile，而且這錯誤觀念到了 Trend，依然沒有修正。因為當時部門所作的 network appliance 是 x86 base，程式則是 C/C++ 在 userspace 當一般 Linux program 來寫，差異只是跟 QNAP 一樣用 Makefile 硬做了一套充滿 hardcode 的 build system，所以比較麻煩點而已。真正重要的東西都沒學到，但至少對 unix system programming 有了比較好的基礎。

初生之犢，傻頭傻腦，建議我去 TrendMicro 的 QNAP 同事，以及當時還在 Trend 任職的介紹人，在知道我分配到的上司是某某人後，都有一些耐人尋味的反應。那些反應當下我不懂，不過現在算是懂了。他不是好老闆，我也太嫩不懂應付，一年多後就在考績被打 D 的情況下負氣離開，打算自己接案過活。離開前我問某高手同事，為何願意執行某些不合理要求，他說「我就做啊，反正到時候他自己會發現不行」。這句話可說比我在那裡全部其他經驗總和都還要震撼，也終於理解為何儘管高手如雲，部門開發的軟體中，卻仍存有一些愚笨的設計。

現在回憶起來，職涯中做錯的事實在不可勝數，但離開 TrendMicro 自行接案，卻是我最好的決定之一。Trend 給我很好的基礎知識與訓練，讓我在接案那段時光中能夠自行學習與成長，在那期間學了 Python，至今都還非常喜歡，並開始對 open source 有更多接觸，進而加入了帶給我決定性轉變的 Openmoko。

在 Openmoko 真正開了眼界。Sean Moss-pultz 以他超凡的個人魅力集結了國內國外都堪稱頂尖的團隊，國外人馬如 Harald Welte, Michael Lauer,  Werner Almesberger 到後來的 Andy Green，國內如 Jserv, Olv, Tick 等人，搭配上開放的組織文化，我有種回到家的歸屬感，也真心相信可以在台灣做出一些什麼。這是一個站上世界舞台的機會，而且不是硬體品牌、代工，而是從裡到外，由 OS 到硬體，完全開放且自製的手機。

然而，夢想歸夢想，築夢仍需踏實。OM 自從換用一位錯誤的 CTO 之後，就漸走下坡，原本成員包括 Harald, Jserv 一個個離開，原技術團隊與 CTO 以及他帶來的人馬之間磨擦不斷，經營情況與氣氛都每下愈況。但這是一間真正讓我有認同感的公司，而且有非常喜歡的同事，我仍然相信一開始創立公司的那個 Sean，所以持續盡力去溝通。我認為這樣一個團隊，如果能夠不要有那些無謂的政治干預，絕對是有機會成功的。

可能是由於這樣的努力，在後期瀕臨破裂的時刻，Sean 做出一個大膽決定，指派我作為台灣工程團隊的負責人，給了三個月時間來做出一些成果。當時實在很高興，因為以那時的團隊實力，跟互相合作順利愉快的程度，三個月是綽綽有餘了。然而真正開始執行以後，由一些小地方，慢慢發現事情不是想像的那麼簡單。明明工程上一個暫時的決定，卻被解釋成長期的離譜判斷。在技術上決定性的差異，被解釋為不重要的細節等等。但這些都是經由旁敲側擊發現，實際上不確定未參與的會議發生什麼事，以及 Sean 究竟如何理解。此時心中竟然警鐘未響，僅僅想著三個月之後拿出成果就是了。我犯下關於人的，不可彌補的巨大錯誤。

於是，三個月變為不到一個月，在 CTO 強力鼓動下，Sean 打破承諾，解散團隊，開除大部分成員。我雖仍保有工作，但心下雪亮，對我動手，不過是時間問題。失去大部分同伴，OM 對我而言，也已經永遠失去了。等到離開那天終於到來，CTO 甚至懶得跟我解釋，我也沒問，彼此心照不宣。想起前陣子，一位之前公司的高層問我願不願回鍋，席間談及若回去，希望能穩定不要跳槽。我回答，從 Openmoko 以後，每一個工作，都是打定主意想長久做下去。離開，從來都不是我願意的選擇。

之後耳聞了一些 CTO 在 OM 的後續發展，原來他一直計畫在上海成立自己的公司，並且挪用 OM 資源去培養。Sean 後來告訴我僱用那位 CTO，是他在 OM 犯下最大的錯誤。相對地，即便已經察覺問題本質，而且有直接跟 Sean 溝通的管道，仍沒有足夠警覺性與手段去處理，則是我犯的最大錯誤，也對不起相信我並託付我溝通責任的台灣團隊。OM 的這群同事們，在戰火下培養出革命情感，雖已離開 OM，仍希望能一起工作。大家商討，都覺得當時剛開放出來不久的 Android，會是之後的趨勢，便決定集中研究。而之前離開 OM 的 Jserv 也回來加入，還多了 TrendMicro 時認識的 Thinker 為生力軍，大家仍推我帶頭，打算共創一番事業。這也就是之後圈內人所知的 0xlab。

在帶領 0xlab 這樣一個技術頂尖的團隊期間，我做了許多決策。其中有些後來證明是正確的，有些則是愚不可及；而有些，則是致命的錯誤。例如在成立之初，便決定以上游為目標，努力尋找進入 upstream 的機會，同時經營自有專案，直接以英文社群為主要舞台，配合贊助公司（也就是雇主）海華科技的業界關係齊頭並進，最終成功建立起直接對應到 TI, Broadcom, Qualcomm, Marvell 等大廠，甚至 Google Android 的工程管道。我們的主要專案 0xdroid 獲得廣泛應用與關注、Olv 成功進入 mesa 上游開發、Walkingice 以及 Bizkit 做的 0xbench 被大廠相繼採用、Erin 負責的 bluetooth 相關應用得到 Atheros 注意、Tick 成了 Broadcom 藍芽與 p2p 專家、Matt 與 Kanru 做了快速開機、Jserv 等人的 patch 進了 Android upstream，0xlab 並在 2.2 ~ 2.3.x 版間排名 Android 第十大貢獻者等等。期間並有幸接觸許多尊敬的前輩，包括台大資工教授也是 Android 核心開發者的廖世偉教授，以及中正的羅習五教授，還有國外的 David Rusling、Paul McKenney 等人。

對於資源有限下如何開發以 Android 為基礎的移動裝置，我們決定以社群為基礎，自行設計 UI 差異化，完全開放原始碼，發行一台初期以社群為主的裝置。這樣的作法與小米手機類似，但當然執行面條件完全不同，雖有正確看法，但對這需要怎樣規模的資源，以及如何執行是完全無知。再比如針對 Android 與各 IC 大廠整合問題，也希望以開放方式整合，使各廠所需投入資源減低，並有一共通基礎；這正是日後 Linaro 基於 ARM 在 Android 所想要達成的目標，也促成了彼此後來的合作。當時在 WMC 2011 展出的視訊 WiFi 無縫切換到大螢幕技術，現在也已經普及。

就我個人角色而言，面對如此出色的團隊，以及過去工作經驗，對領導的想像是，應該要提供一適合工程師工作的環境，並處理所有工程以外的問題，包括商業面所有事務，讓團隊能夠專心開發，不受打擾。為了達成此目標，我認為應該退出研發，將此責任交給技術名人 Jserv，把自己定位在柴米油鹽的商業面上。另外經由開放源碼的方式，讓團隊成員建立自己的 credit，累積成 0xlab 的 credit，自己只需隱身幕後，0xlab 的成功，便是我的成功。事實證明，方向雖有道理，但這決定是超乎想像的愚蠢，也對我自身造成深遠傷害，至今仍受影響。

不論能力是否最好，要領導，就要親力親為。就 0xlab 的例子，自己不做，會漸漸喪失對研發的直覺，也會與真實情況脫節，更別提在只看技術的開發者眼裡，會從一個還可以的工程師，變成一個忘記怎麼寫程式的笨蛋。另一個關鍵則是，當工程師建立起自己的 credit，就會有相應的工作機會出現。面對來自歐美公司的高薪挖角、優渥條件，或是大公司的工作機會，0xlab 其實是沒有競爭力的，這導致幾位夥伴相繼出走。日後才理解到，這完全是我自身的問題，搞錯了友誼與工作之間的關係。要防止這種事情的發生，並不是靠交情而已，還要加上商業與法律上的種種方式，將眾人利益確實捆綁在一起，確保目標一致才行。如果光講交情，朋友找到好的工作，還應該要恭喜他呢。然而對於新創事業，接二連三失去珍貴人才，是不能允許的。

至於 0xlab 是如何失敗的，我了解的範圍應該很接近全盤事實，有人比我知道更多，但也無須深究。這件事應該永遠都不會公開，因為在有人感興趣時，這件事不該說，說了對誰都沒好處。等到沒人感興趣，就更不用說了。總之，當時情形一片大好，無論在資金、已有生意、未來發展等方面，都看似毫無問題。然而因為沒有站在各人立場去通盤考慮利害關係，對人性缺乏理解，誤信人言，最終遭到背叛，是我再度在關於人的判斷上，犯下大錯。一夕之間，大好轉為大壞，那陣子不論經濟上、精神上，都經歷巨大創傷，更別提還有認識的人落井下石。

在事件發生之後，整整一年都無所事事，一方面官司陰影籠罩，另一方面也尚未從打擊中恢復過來。往好處看，這段期間讓我重新排列生命中人事物的重要性，懂得該珍惜什麼；也經由這次打擊，真正把自己從以往著迷 RPG 與武俠故事，滿腦子都是義氣熱血與友情的傻瓜中稍微拯救出來，對世界的真相多一些了解。

或許是學不到乖吧，時間走到近兩年，仍是在新創公司打滾，對台灣環境、產業、商業操作，更重要的是社會真正運行的方式，有更多的體會。雖然仍然不時有愚蠢的失誤，畢竟還是活了下來，也做出了點成果，比起以往是好多了。一切還言之過早，就繼續努力，且看機運是否配合吧。

就在這幾天，陪伴17年的寵物貓咪走了，非常傷心，也再度理解到，不論職涯如何，對我而言，最重要的是身旁珍惜的一切。有人說做自己喜歡的事情最重要，我說，喜歡一開始只要有一些就可以了，能夠讓自己有能力照顧珍惜的東西，才是最重要的。做到這點，就會自然而然更喜歡在做的事情了。成功也好，失敗也罷，都不該忘記這才是最終目標、動力來源、以及真正快樂的方法。

Hack Everything

是一句陳腔濫調。但話雖相同，對我來說有自己的解釋。

一直以來對於討厭的事情總是避開，但這常常造成阻礙。避免去碰是沒有信心：對於其中種種細微處是否能吻合自身價值觀、對於能否掌握界線沒有把握。但不去做就無法取得資源，而當嘗試困難、且無法以一人之力辦到的事情時，一切有用的資源都該想法子取得。

1. Understand the rules.

2. Play by the rules.

3. Exploit the rules.

Hack everything.

發脾氣中...

尋找新定位不是那麼簡單。首先要理解，自己的能力不足以對每件事情有深入理解，所以要找到平衡點。平衡點不那麼好抓，必須足夠到有概括但正確的認識，卻也不能過頭壓縮到其他事情。此時要小心的選擇學習什麼，以及學習到什麼程度。

在這過程中無可避免會有一些危險，以工程師的術語來說，就是嘴砲化。我不想變成我厭惡的類型，所以我不願放棄developer的身份跟個性，這需要一些自我要求...還有紀律。這根本就是我最欠缺的東西啊。幸好，程式還是很親切而且令人愉悅的，且實做對學習新知也有極大的幫助。

最惱人的就是外在的干擾。對於某些人的challenge覺得很厭煩，最令人反感的是那種愚蠢。感覺好像是幾個人在畫畫，然後旁邊一直有人叫囂說他畫架做得比較好...研發工作並不是互斥，別人做得比較好或比較壞，可以是一種互相合作的關係而不是排斥。整個公司也才多大、整個台灣也才多大，要找競爭，世界上多得是，為什麼小鼻子小眼睛的光看一些技而不是藝。這不是正巧落實了Wolfgang那德國垃圾說的話：台灣沒有Apple是有原因的。馬的。

莫忘初衷

許多朋友或許都已耳聞，最近職場上我碰到一些不愉快的事情。世上總會有人放暗箭、玩小手段，也總不缺乏失格的領導人。這些都是無法控制的，能控制的只有自己，如何免疫、反擊、甚至獲勝。

我花了很多時間思考這問題，思考如何從這經驗中獲取教訓，日後該如何面對，也一度覺得價值觀破毀。當你努力執行過，也獲致不錯的成果，但權力者卻由個人好惡而攻擊、打壓，此時該如何自處？努力工作真的有用，還是該花時間拍馬逢迎？以後該如何做事呢？

感謝許多人的聆聽、建議，我還是沒有獲得答案，但至少已經走出這思考死結。命運、緣份等等是沒有正確解答的，人只能等待並做好準備。我學到了重要的一課，就是圓滑、避免正面衝突，迂迴前進，有時才是正確的路徑。學到以後，就不需要再往後看，直起身再往前走，看看命運之後會給出甚麼，也就是了。

展望前程，正直、踏實仍然是我的本心，手段可以變，本心不能變，變了就不是我了。當失去自我，獲得世界又有甚麼意義呢。

職場人生

"This fall I think you're riding for - it's a special kind of fall, a horrible kind. The man falling isn't permitted to feel or hear himself hit bottom. He just keeps falling and falling. The whole arrangement's designed for men who, at some time or other in their lives, were looking for something their own environment couldn't supply them with. Or they thought their own environment couldn't supply them with. So they gave up looking. They gave it up before they ever really even got started. You follow me?"

我想像你這樣騎馬瞎跑，將來要是摔下來，可不是好玩的－－那會是非同小可的一跤。摔下來的人，都感覺不到也聽不見自己著地。只是一股腦往下摔。這整個狀況是為哪種人安排的呢？只是為某一種人，他們在一生中這一時期或那一時期，想要尋找某種他們周遭環境無法提供的東西，或者尋找只是他們認為周遭環境無法提供的東西，於是他們停止尋找。他們甚至在還未真正開始尋找之前就已停止尋找。你在聽我說嗎？

"Among other things, you'll find that you're not the first person who was ever confused and frightened and even sickened by human behavior. You're by no means alone on that score, you'll be excited and stimulated to know. Many, many men have been just as troubled morally and spiritually as you are right now. Happily, some of them kept records of their troubles. You'll learn from them - if you want to. Just as someday, if you have something to offer, someone will learn something from you. It's a beautiful reciprocal arrangement. And it isn't education. It's history. It's poetry."

其中的一門知識就是，你將發現你並不是第一個對人類行為感到惶惑、恐懼、甚至噁心的人，在這方面你倒是一點也不孤獨，你知道後一定會覺得興奮，一定會受到鼓勵。歷史上有許許多多人都像你現在這樣，在道德上和精神上都有過徬徨的時期。幸而，他們當中有幾個將自己徬徨的經過紀錄下來了。你可以向他們學習－－只要你願意。正如有朝一日你若有什麼貢獻，別人也可以向你學習。這真是個極妙的輪迴安排。而且這不是教育。這是歷史。這是詩。

~ J.D. Salinger, The Catcher in the Rye.
沙林傑，《麥田捕手》

程式設計師的經濟學

有個問題困擾我很久了。長久以來，我一向對軟體工程師的待遇感到很困惑：是的，通常他們在所處的社會中應該可拿到中位數以上的薪資，但工作本身的難度與所需持續付出的努力，與薪資水平似乎不成正比。

以我較熟悉的職業來說，商業管理路線，除了工作時間外，需要的充實自我大概是商業評論刊物，中英文報紙等等，有些需要精讀，但不是做學問，你不需對著一篇論文苦參。又或是新聞媒體：是的，工作時間外仍需要注意時事，但你不需要在假日研究最近有甚麼新的新聞理論。

工程師就完全不同。一旦停止學習，你就掉入後段班，等待被淘汰。這裡說的學習是真正紮實的：你必須閱讀通訊協定、理解各種技術文件、了解演算法，偶爾溫習一些數學、電子物理等等。這些是需要用做學問的努力去面對的東西。這種職業一般稱為專業人士，具有某種經過訓練得來的特殊技能，進入門坎較高。然而在我有限的知識中，沒有類似的專業人士需要付出這麼高的維護費用。律師、會計師、醫師，都會有一段辛苦的養成過程，但養成之後，維護費用相對較低，沒有這麼辛苦。

軟體工程師經常有華爾街的工作時間、律師的職業挑戰、醫師的工作壓力。但是，他們的收入通常比起這些職業，都還有段差距。這讓我百思不解。

晚餐時與同事聊起，讓我決定再挑戰一次。這是個經濟學問題，供給與需求，而價格基本上是由這兩者決定。接下來我想到世界上跳踢最高的人，然後，我好像突然懂了一點。

跳踢最高的人？甚麼跟甚麼啊？

這是之前看到的金氏世界紀錄節目。那集有紀錄保持人跟挑戰者，紀錄保持人看來毫不特殊，自稱沒有特別鍛鍊；挑戰者則是穿著緊身衣繃著一身的肌肉，顯然狠狠的練過，勢在必得。結果卻出乎意料：紀錄保持人輕鬆的打破自己的紀錄，而挑戰者怎麼也跟不上他那看似簡單的動作。

很明顯，衛冕者具有某種罕見的才能：跳踢。在具有這種才能的人們中，他是世界第一。問題來了：如果比較世界前一百名擅長跳踢者的薪水，與前一百名擅長財務操作者的薪水，讀者覺得哪個平均會比較高呢？

這個例子讓我理解到，才能、難度是一回事，但這種技能可以為你獲得的利益則是另外一回事。有了很棒的供給，還要注意有沒有夠大的需求。明顯的，我們需要不少會賺錢的金融人才，但卻不需要很多跳踢很高的人，儘管他很厲害，而且這才能很罕見。

那讓我們觀察軟體市場的「需求」吧。軟體的特色是甚麼？複製的阻力幾乎沒有。這意味著，我們並不需要很多從非常好到普通好到不怎麼樣的軟體，我們只需要一套最好的就行了。我們不需要二十種搜尋引擎、二十種網路瀏覽器、二十種作業系統。大部分人用的軟體都差不多。

於是我理解到一個冷硬的事實：世界並不需要很多軟體。如果你是能夠設計出常用軟體的工程師，那麼你會得到非常棒的報酬。但，如果你不是，那麼請準備好接炸彈：

並沒有人想要用你做出來的廢物。儘管你以及你公司花了那麼多錢財與心血，但如果它不是前五名，它就是廢物。廢物賣不了錢，所以你當然沒賺頭。如果不是最好的，市場就從華爾街變成跳踢了。

這點一想通，我有恍然大悟的感覺。好的室內設計師並沒有辦法把他的巧思大量的複製。我們可以用相同的搜尋引擎，但不想住在裝潢都一樣的房子裡。而如果需要對每棟房子做風格相同但細節不同的客製化，就無法大量生產。所以，一名超級厲害的設計師並沒有辦法統治世界，讓其他的同業都沒飯吃，但是一個很強的搜尋引擎卻可以。同理可證：Armani 很貴，Net 很便宜，但軟體可以很輕鬆的用 Armani 的品質賣 Net 的價錢，然後把 Net 擊潰。

意思是，軟體設計師是贏者全拿的。你要嘛就是最好的（此處的最好，是指最受歡迎，不是指技術最難），要嘛你就乖乖領那點薪水吧。

因應策略則是：

如果你是最好的那類工程師，恭喜你。

如果目標是薪水最大化，那你不該選擇你最擅長的事情作為職業。你應該選擇薪水最高的。

如果薪水不是最重要的，那將薪水以外的事情列入考慮。如果你喜歡工程的單純與愉悅，那麼這也是你的所得，金錢跟快樂都是報償。反之，如果你並不能從工程中獲得快樂，那麼請思考是否轉行吧。

最後，下次覺得不公平時，請記得告訴自己：「跳踢也很難啊」。

迷惘...

方才逛到某已婚婦女相簿，翻了幾頁，心裡突然覺得很憂傷。很多事情我真的不懂。

我對自己的懷疑是，為何我總是沒辦法用想做的事情賺到我想要的生活。當然很多資訊會告訴你築夢踏實的人最後會得到更大的報酬，例如 Steve Jobs 大師開示的 Stay hungry. Stay foolish. 我一直嘗試在做，但是似乎只有 stay foolish 而沒有 stay hungry. 實情是我對 RD 已經沒有熱情，也沒有「足夠」能力去做我想做的事。

既然都沒熱情，既然我喜歡的只是沒生產力的享樂，那就應該尋找投資報酬率最高的工作才是。照這樣的思考，留在現在這間裡想性濃厚、薪水奇低的創業公司，就是個很蠢的主意。(Stay foolish, remember?) 真正該做的事情是找間高薪公司，朝九晚五然後把 day job 以外的時間拿去追求自我。既然工作就只是工作，又何必考慮理想這種不能吃的東西。

會這樣寫，就是很希望能說服自己。對我來說，現階段在做的事情是我對"hungry, foolish"的最後一次嘗試。我知道我離開了就是永遠離開，就是放棄，就是把人生走回安份守己的布爾喬亞。

然後，我的年輕時代就真的結束了。

笨工程師們，不要再無償加班了！

以前我就 post 過這篇。英文附在後頭，翻譯在前頭，希望可以多點醒幾位傻蛋。這文章是我在 slashdot 看到的。

Re: 誰死了讓你變成老闆啦？
> 如果有人就是喜歡一直工作，為什麼不尊敬這點，去管你自己的生活就好？

如果這不會打擾到我的生活，當然沒問題。但是，如果你每週七天，一天24小時的工作，而我們共同的老闆想知道為何我一天無法完成20件工作，這就很討厭，此時你的工作習慣就影響到我了。如果我們的共同老闆決定讓你的態度成為「正常」而期待每個人都做到，那你就創造了一個讓人過勞的工作環境，此時你的工作習慣就影響到我了。如果你養成了24小時工作的習慣，而你感冒了但還是照常上班，因此傳染到我，此時你的工作習慣就影響到我了。你傳染到我，我該死的就一定在家休養，其他被你傳染的人若是還有理性也該在家休息。

容許一部份人在工作環境中做出這種有害的行為，會設立一種有害的慣例，因為沒人是在隔絕的泡泡裡頭工作的。這會改變工作的文化，導致利益向組織過度傾斜而忽視個人權益。這會產生健康危機，潛在的危及整個社會的經濟。這是我為何會在意「你」把你自己操的過勞。因為此時你不只是我的同事，還變成了我周圍世界的氣壓計。

以上，看懂了嗎？在這個賽局中，一旦老闆決定「我要責怪其他人沒有向工作超時的人看齊」，此時組織就可以在不多付錢的情況下把大家燒乾，最後只要留下沒掛的人傳承經驗就行了。畢竟新人還更便宜。此時唯一解法只有員工自行團結，才能維持平衡。這麼多過勞死的新聞難道沒響起警鐘嗎？不要以為人是操不壞的。

John Nash 在 A Beautiful Mind 裡頭的策略還記得吧？如果硬要當那個愛表現超時工作的，下場也許是自己拿12分然後得腦瘤死掉。但如果大家合作，也許所有人都可拿10分，而且除了工作以外還可以擁有自己的人生。用腦想想吧，幹麼把自己做那麼賤？


Re:Who died and made you boss?
(Score:5, Insightful)
by Techguy666 (759128) on Wednesday June 27, @12:21PM (#19664409)

If someone likes working all the time, why not respect that and move on with your life?

As long as it doesn't intrude on my life, I'm all for that. However, if you work 24/7 and our mutual boss wants to know why I'm not accomplishing 20 tasks a day, that gets annoying and your work habit is affecting me. If our mutual boss decides to make you the "norm" and expects everyone to follow suit, then you've created an environment for burnout and your work habit is affecting me. If you get in the habit of working 24/7 and you catch a cold and come in to work anyway, and I catch your cold, your work habit is affecting me. You infect me with a cold and I'm staying home, dammit. You infect other, saner, people and they'll stay home too.

Allowing someone to behave detrimentally in a work environment sets a dangerous precedent because nobody works in a bubble; it changes the work culture to one that benefits the organization unequally over the individual, it creates health risks, and combined, potentially skews a society's economy. That's why I care if *you* work yourself to the bone. You're not only my colleague but you're a barometer of the world around me.

溝通、溝通、溝通

相信許多人都有跟外國人合作的經驗。有些是公司對公司，有些是公司內不同部門，也有些更極端的例子，就是在每天的工作環境中跟外國人直接合作。合作的程度越高、越細，溝通的問題就會變得更加明顯。

台灣RD個性不喜歡自我宣傳，做了事情就平鋪直敘擺著，等著有人自己去看。尤其不喜指責，往往事情真相，只會在同事間私下閒聊才知，而非公開討論。彼此都是台灣人時，問題比較小，因為文化相同，會特別注意。觀者有慧眼、夠內行，對效益如何、做多做少，多半就有個底。不過對方是外國人時，沒講經常等於沒做，沒聽到就是不知道，事情經常就比較麻煩。

比如這陣子，老外大老闆(以下稱W先生)老是把人抓去review，也會檢查這段時間內工程師寫的程式碼。有位程度相當不錯的同事在接受review時，W下命令檢查他寫了多少行程式。這當然是件超級蠢的事情，尤其他平時對每人工作細節了解有限，似乎應該了解這些程式碼「做了什麼」比較有用。結果是這位同事心情相當不好，但也只是很委婉的表達，我很確定W根本不知道他有意見。

這當然很可能是誤會，也很可能是W真的就那麼草包。但是，在沒有明確表達的情況下，工程師得到了錯誤的評價，直接影響到自身職涯，W對情況也仍然不了解，問題完全沒有解決，所有人都輸。同樣一個W先生曾經在讀過我對一位外國人的回信之後，認為我過於間接、委婉，而寫了這樣一段話給我：

Remember you are talking to typical ignorant Westerners here. Unless they hear crystal clear that you think they delivered shit, they will still believe you must be the happiest man alive to be able to work with them.

「請記得你是在對典型的西方白痴講話。除非你很明確的告訴他，他做的是屁，不然他會認為，你覺得能跟他合作是世界上最棒的事情。」

同樣的話完全可以適用大部份外國人，包括w先生自己。如果對於這些傢伙有什麼意見，把話直接丟到他們臉上就是了。他們就是這樣受的教育，鼓勵表達意見。只要把握客觀、不情緒化的原則，直接了當的對話就是最好的。

三十歲的五十肩

a.k.a. 如何用工作搞爛自己的身體

某天清晨由睡夢中醒來，一時還不知原因為何，傻了一會才發現是雙肩劇痛的緣故。洗了把臉，還是痛。決定不管，回去睡覺。起床後更是受不了，坐在椅上動彈不得。乾脆打電話請假，去看中醫。

才解釋幾句，醫生就開口說這是五十肩。之所以叫這名字，意味著好發於五十歲左右，卻在我這未滿(是的，未滿)三十歲的身上發作。直接原因是，睡覺時沒有著重肩部保暖；遠因則是，前陣子亞力山大歇業，我沒有晚上運動的時間壓力，加班過久。少運動又加班，等於是雙重損耗。

對程式員來說，放下做一半的工作是很困難的。我想做到一階段再放下應該是可以允許，然而必須注意叫自己不要繼續做上件工作中想到的附帶事項，轉而寫下摘要，留給明天。不然，搞到自己的career提早結束，也非想要的結果。

Ideas about OpenMoko.

Need to scratch my ideas here:

1. iPhone is fun. But it's closed.
2. Android is opened. But it's boring.
   
3. OpenMoko is opened. And it should be fun.
   

國王的耳朵，是驢子的耳朵！

要好好的寫下腦中想法是困難的。近來發現自己的思考方式開始跳躍，也許可以說服自己是因為缺乏充分的時間好好詳述，但更可能的是：或許根本不存在推理過程，僅僅是跳到結論而已。

要了解一個組織內部是否產生問題，很好的觀察法是，「國王的耳朵明明就是驢子的耳朵」這現象有沒有發生。意思就是，會不會「明明是個五歲小孩都看得出來的笨主意，高層卻脫離現實，振振有詞的認為可行，大家也不吭聲。」舉國民黨為例，選舉一輸再輸，內部討論認為是不夠貼近「本土」、「年青人」，最後出來的策略竟然是用這樣的字眼：「他"馬"的就是愛台灣」、「藍鳥」(懶叫)、趕羚羊之聲電台->LP 之聲 (love and peace??) 、藍教頭... 這真是侮蔑年青人，東施效顰不得要領。偏偏五歲小孩都知道不對的事情，一群人卻花錢熱熱鬧鬧的做了出來，這時我們就知道，這黨有大麻煩啦。

我認為，以上狀況目前在敝公司已經發生。這篇文章是為了明確紀錄當下想法，以供日後驗證。例如有次會議討論無線網路相關功能，高層認為我們的手機「不該支援連結到加密無線網路」。許多人都會把家中的無線網路加上密碼，一來避免遭人佔用頻寬，二來也免得個人資料被竊聽。如果要花那麼多錢買一支具有無線網路功能的手機，卻連自己家的網路都不能連上，其他功能與外型也並不出色，我實在不知道如何花得下手。更何況，手機上又沒有網路插頭，如果不能用無線網路連，怎麼上網？(當然啦，有許多其他方法，不過對一般使用者太麻煩了)

Believe it or not，工程師的反對意見直到請出了 CEO 仍然不被採納。高層認為工程師不懂行銷，對產品規格指指點點是撈過了界，採用了相當高壓的方式叫工程師閉嘴。直到第二天，CEO 經過了思考，也認為「不能連到家裡的無線網路」似乎是個笨主意。嘿，雖然這件事竟然要一天才想通有點扯，但至少想通了，算是好事。不過很可惜，好戲剛開始啊。

經過許多摩擦，週五明確宣佈公司政策，簡而言之，以產品為導向，行銷帶頭訂立規格，而研發部門負責執行。研發部門回報各功能所需資源，供決策者以出貨時間以及成本為考量來取捨。研發部門明確禁止對產品規格說三道四。非常非常典型而且標準的流程。我必須說，在某些公司，這是正確的執行方式。但對於我們而言，不是。

Smart phone 並不是什麼新出現的市場。它在那好幾年了，相關硬體已經發展得相當完備，軟體也百家爭鳴，Nokia, Microsoft, Motorola 等等都已經有了自己的平台。我們的獨特處並不在於我們做了一支更棒的手機，而在於我們是第一支軟硬體都完全 open source 的手機。這開啟無限可能。除此之外，機身厚重、外型不佳、開機三小時電池就乾掉，面對現實吧，我們根本輸人一大截。軟體面也是，任何一支聽過的品牌手機都超過我們，更別提 iPhone 了。但它的強項是，這支手機上的軟體可以自行修改、創造，使其獨一無二，只要你有能力。這是吸引工程師的特色，而非吸引一般消費者。而直到目前為止，我們所有的顧客正是工程師，與我們這些公司內意見特多的死工程師是同一群人。想多賣些手機、想知道顧客的需求，應該去問問這些工程師，而不是叫他們閉嘴只管做事就好。

Open source 是我們唯一該走的路，可以超越硬體平台的限制而自由進化。假以時日，就如同 Ubuntu 明確的超越 Windows 成為更適合普羅大眾的作業系統，open 的手機平台也會有那一天，而我們應該等待那果實收成。在這時間點剝奪工程師的創意，使其為行銷部門的產品概念服務，直接針對普羅大眾的消費電子市場，而非以市集方式(請參考Cathedral and bazaar) 隨使用者需求演化、針對小而美的利基市場經營。這樣的作法明確顯示了經營者的壓力以及野心，對投資者更好交代，但卻直接離開了自身最堅強的戰場，而在最弱的產品面與巨人對決。我相信這樣的大方向是錯誤的。不過我也認為真正執行起來，這策略仍有可能成為另一個被遺忘的口號，最終我們還是自然/不可抗的回到開放軟體社群的世界。這會是我樂見結果。

回到工作上來說，我領悟到，如果對已經決定的策略這麼有意見，那應該自己去開一間，而不是以員工身份指指點點。公司是專制政體，在評估階段，各陳己見是恰當的。但命令一下，就算指出皇帝錯誤的人是對的，皇帝當然也是先斬了這不識相的傢伙，然後隔陣子再睿智的換個說法自我修正。所以：

1. 如果我根本是錯的，高層方向正確，最後帶大家到達應許之地，那我不講比較好。
2. 如果我是對的，因為會先被斬掉，所以也享受不到方向修正的好處，還是一樣不講比較好。

結論很明確：在blog上抱怨已經是最大極限，閉嘴，做好本份就行了！

@openmoko.com

很快的更新一下我的現況。最近太忙，連寫 blog 的閒情都沒。

從上週開始回到職場，在 openmoko.com 工作。公司到目前尚未跑完登記程序，也就是還沒成立。core team 包括 Sean Moss-Pultz, Harald 'LaForge' Welte and Michael ‘Mickey’ Lauer. 台灣這邊則包括 jserv, OLV (freetype developer)等人。

略查一下的話可以發現這是非常恐怖的團隊，例如 LaForge 是 netfilter/iptables 的主要作者，Mickey 則是 OpenEmbedded 創始者。最驚人也最令人慚愧的是，以上提到的這些開發者，除了 Mickey 以外，全部比我年輕。所謂歲月不饒人，我在吃喝玩樂的時候，很多人可是認真的在研究呢。總之是間非常有趣的公司，靜觀其變。

另一件事情，之前拿來當作工作室的安東街公寓，原是鐵路局員工宿舍，現在確定遲早要收回了。另找了間套房租下來，現在得處理搬家事務，講起來真是多如牛毛。總之變動可以視為常態，塵埃落定之後，且看這一波人生轉折會有甚麼結果吧。

幡然有悟

不知為何，這陣子以來，心情持續感到一種平靜。莫名的就出了這標題。

其實是不應該平靜的。出租的房子最近問題一直很多，當年貿然無知的找人裝潢，又沒有監工，現在問題就一一冒出，還得面對敷衍欺騙客戶的水電工人。財務麻煩不小，畢竟現在的生活方式也不過是把債務延後用以維持生活罷了。

我想原因應該是最近做的一個案子。說真的並不是很難的工作，雖說有部分不熟悉，但有原先的程式碼可參考，評估一下也就接了。似乎案主挺高興的，應該是燙手山芋，時間又趕。真的做下去，果然發現問題很多，規格不明、變數多、文件與資料都欠奉，但總之最後都找到方法繞過問題。需要對方提供資料所以卡住的時候，就先切換到不會卡住的地方繼續做。

我發現，我似乎自動地在做著一些以前會讓我不滿的事情。工作態度以及心態上似乎都微妙地改變了。這一年多來的經歷，大概是我人生最缺錢最困苦的時期，但從那中間，我好像領悟了些甚麼，思考的方式不自覺地延著與一年前不同的迴路在運作著。

自己最大的問題，是我總是從錯誤中學習，而非直接由別人經驗學到。世上可犯的錯誤很多，有些錯誤的後果是擔負不起的。至今為此我已經付出很大代價。

但好處是，一旦我學到甚麼，最終修正到了正途，便總有莫名的篤定，似乎知道繼續走就對了。對人生，我從來不是很講邏輯，總是憑著感覺任性的前進。也許這次的經驗讓我感到，還是有些能力可以運用，只是要找出適合的場域。很奇怪的我並不擔心，時機總會來到，若永遠沒有，也是命定，但求無愧於心。

專案小故事

許多想法在心裡待了好一陣子，把他們寫下來後，會整理得比較清楚，並且正好以此檢驗自己。

之前提到過，我參與過高鐵的票務系統開發，此事還有後續。案子結束後一陣子，原案主找上門來，希望能機動支援同系統相關工作。之前我已經向案主表明過，不太願意再接類似性質的案，但基於我對此系統已有一定了解，還有想賺錢，仍答應去瞧瞧。這次主要內容為 UI 的改寫，整個皮要換過一通，而當然，由於 view/ control 切得並不好，換皮絕對不好換。主要的工作已經由一位 M 開頭的工程師在執行，但案主認為人力不足，無法如期完成，我大概了解情況後，這位工程師抵達，我們進去開會。

會議中我表達意見，認為原系統雖然寫得不好，但已經通過各種測試，所以若要修改，建議以原有程式為基礎，盡量用換圖片，改位置等等方法改正。不過 M 很有自己想法，已經用 wicket (那時我第一次聽到) framework 而非原先的 struts 加以重寫 / 重整，對此我表達反對，連 framework 都換，勢必重測、修正，案子時程趕，不宜。案主則表示，希望 M 先提出需要幫忙的部份，看看 John (就是我) 有什麼能做的。 M 提出的是，請我幫忙把要翻譯的字串從網頁中標記抽出，拉到文字檔中即可。這是相當單純的工作。

我沒什麼意見，總之如果案子需要的是這樣，我們就做這樣吧，只是不要期待我花自己的時間下去做就是了。不過既然案主的意思是希望我能幫就盡量幫，基於敬業，就算這麼簡單，我還是希望了解一下目前情況，讀讀程式碼，最好是架個環境，抽完字串後能自行先檢查一次。所料未及的是，此舉卻遭到 M 的反對，他不願釋出程式碼，也不願其他人有更多參與，並表示我只負責抽字串算不上什麼寫程式，不需要知道。

嗯，整件事由我的角度看到的是這樣，檯面下有什麼其他東西我或許不知。例如案主告訴我，如果 M 一定時間搞不定，希望由我全部接手，我相信這件事情他就不知道。相反地，或許不釋出程式碼是案主的意思，或是 M 只是想自我保護，都有可能。不過結果是，我被 M 的傲慢徹底激怒了。

有個專案的執行原則是，盡量把所有資訊公開，並鼓勵成員對於 the whole picture 有一定了解。當每個人都清楚自己在做的是什麼、以及為何而做，對專案就是正面的。此事無涉保密原則，因為我已擁有全部（包括UI以外）的程式碼備份，對我保密毫無意義。M 那種認定我很強可以一人搞定，你們小雜兵只要幹一些我給的幼稚園雜務就好，其他事情不需知道的想法，對專案絕對是負面的，也不利 teamwork。更別提我們初次見面，他甚至連我的底細都還摸不清，便直接採取了這種態度。

嗯，這是第一個故事。接下來是第二個。

話說我們之後做的一個大案子，搞得很慘，規模完全超乎能力之外，當初講義氣答應的時候，實在太天真。無可避免的上網找幫手，一間公司派了工程師以及專案經理過來。此工程師姑且稱之為 L 吧，開場白就告訴我他在某雜誌開了 Java 專欄，並且表示對各種 opensource 的 framework 「都很熟」，「不熟的看一下就會了」。接下來開始討論，他沒兩句就要教育我一下，例如說他會用 Maven，可以拿來幹麼很好用之類的，我只好打斷說，這我已經知道。再過一會他又說起 xxx 如何如何，結果我又只好再度說，這我也知道。

大致談完後，決定過幾天我會收到 demo。果然，我在指定日期準時收到，demo 內容相當完整，還有 screencast 以及文字說明，清晰易懂。

我對 L 的印象，比對 M 好很多，在專業方面他的確有足夠能力執行工作，雖說他的專欄都是介紹性質，難稱 hacker，但我們可視為自我宣傳，無可厚非。

最後是故事三。

我們曾與大陸方面的一些工程師合作。對方的聯絡人我們稱 A，他一開頭並沒對自己介紹很多，只說會做 Java，先問我專案內容、採取的技術等等。我大概簡報了一下用的技術還有系統性質，對於某些不熟悉的技術，他問了些大概，表示他會一些相關的東西，應該可以試著了解看看，並拿了程式碼回去參考。過幾天他開始問我一些關於他原本不熟悉技術的內部問題，很明顯是 survey 過以後才會有的疑惑，我盡我所能告知，並且提供他一些網路文件位置以及 example code 下載。由於大陸方面網路常會被擋，看得出他花了功夫收集資料，收集不到的才來找我要。

接下來開始執行。初期他被不熟悉的東西狠狠擋了一陣子，進度 delay，他一再表達歉意，並且說之後一定趕上。之後他們速度明顯一直增加，隨著熟悉度增進，改的速度也越來越快。問的系統問題有時很深，是自己仔細想過後才問得出來的。

在過程中我們慢慢混熟，他慢慢了解一些我的技術背景，開始問我一些他不熟悉的領域。看得出來他對 Java 的功力其實頗厚，不過他都不講，似乎把自己會的東西看成理所當然，看了他們寫出來的程式碼才感覺到實力。他問的問題，都是集中在我會而他不會的東西，例如 Embedded system/ Linux 等等，甚至一些商業、公司上的事情。最後他在指定的時間達成了專案目標。

第三個故事說完了。現在進入尾聲。

前些天看到某活動網站，赫然發覺 M 也自行申請為講者，講題看來是「介紹」Maven 還有 Wicket，自我介紹說「興趣為 OOA/OOD/OOP、軟體工程以及專案管理領域」，見此心中不無感慨。或許我想表達什麼，或許沒有，就讓他只可意會，不能言傳吧。

心亂如麻中。

最近讀完 George Orwell 的 1984，加上杜正勝大部長最近以九五暫綱為基礎審出的新版歷史教科書，以及神通電腦在高鐵售票系統出的大包，最後還有新彩卷系統上線後當機連連。這些事情看似不相關，然而在我自己也搞不懂怎麼運作的腦中，他們卻又都是相關的。

或許可以說，我身處個人的小危機中。當你慢慢可以看出事物背後的本質、理解來龍去脈，卻不喜歡你看見的東西又無力修改，就會掉入這種危機。

先從售票系統還有彩卷談起吧。我是略略參與過售票系統開發的。那是剛從公司辭職出來，接的第一個專案形式的工作，以約聘形式臨時加入一個月。大概是因為開發已到後期，規格突然有變，人力不足，所以向外找些傭兵。合約的保密規定相當嚴格，我只能說，就當時看到的程式碼，目前系統會有這些問題，並不令人意外。只是在那時點以及槍手身份的職權，我對這種情況也無能為力。

彩卷問題也大同小異。軟體設計並不容易，從前期以及執行中架構的決定，到後期測試方法等等，無一不是學問。而這些系統現在出的狀況，並不是你面對了困難問題，百密一疏所造成的。他們基本的程度，就好像你練短跑卻不懂怎麼起跑、打籃球不懂運球、或者是玩攝影不懂光圈一樣。這代表在整個軟體開發流程中，重要的關鍵動作，從頭到尾都無人做出。這表示有此專業的人並不存在、或是沒有掌權、或是雖有權卻故意省略不做。

這代表：事情大條，並不只是個 bug 這麼簡單而已。整個制度都出問題。就如同你在菜中挑出一隻菜蟲，代表有點小疏忽；但如果一隻大蟑螂自始自終都趴在盤子正中央，而這道菜卻仍然送到顧客的桌上，這時候你就知道，問題不只是疏忽這麼簡單。

更耐人尋味的是，在問題浮現後，神通電腦處理的方式。他們將錯誤導向規格問題，表示是由於高鐵要求的規格「是以航空業標準來規劃」才造成系統現在的狀況。我們必須弄清這動作背後的含意，如果規格有問題，責任就是在高鐵而不是神通，而高鐵如果要修改規格，由於跟專案一開始不同，勢必被科以天價。這也是高鐵後來為甚麼一直放話，表示包商必須無償負責修改，以及系統純粹是設計不佳，與航空業規格無關的原因。這其實都是公司之間的角力。

今天的中國時報「高鐵票務軟體沒寫好 釀成不可思議的亂」大概點出了這個問題，然而其中「科技公司高層」表示的「專業立場」，卻又犯了根本的錯誤：

這位參與過運輸業票務系統的專家分析，台灣高鐵公司之前會發生重覆訂票的事件，很可能是時間差沒控制好。例如，如果甲從十二點零一分零一秒開始自動售票機買票程序，在零一分零五秒才完成程序，而在這空檔期間已有別人搶先一步訂了這個的座位，結果電腦還是回覆甲說座位沒問題，就會造成重覆訂位。

「我們設計軟體，時間差是以毫秒計算。」他表示，多人在同一個毫秒訂下完全一樣座位的機率很低，軟體如此設計就可以避免這種問題。

以上這段話從一開始的正確講到純粹狗屁。就一個高流量系統來講，就算時間差弄到毫秒也一樣不保險，「機率很低」就是不夠好、就是無法避免。目前 CPU 隨便都 1GHz 以上，一毫秒的時間就跑一千個指令了，算到毫秒又怎樣？由時間來處理根本就錯了，這只是最基本最基本的 read/write lock 問題，所有教科書都有。最後還來個老王賣瓜說自己設計軟體都以毫秒計算，這臉豈不丟得更大？我毋寧相信此高層是受害於作者的錯誤理解與引述，而不是他自己真的這麼想。

種種事情不禁讓人害怕，台灣的專業人士都死去哪了？這麼重要的公用系統不能謹慎開發、天天看到記者的不當發問與錯誤報導、資訊軟體業嘴皮子重於實質，打好人脈才是重要... 尊重專業好像成了口號，專業不過是對意識的服務。這就引伸到一九八四這本書，還有杜正勝的事情。

不喜歡文章落落長，下次再說了。

痛苦的領悟

前陣子參加老同學的聚會，我覺得程度很好的一位 I 君說他決定走 presale 的路子，而非 developer。我問他為甚麼，他說寫程式有個缺點，因為你不管怎麼寫，永遠有人比你寫的更好。

回來以後這件事情在我心頭盤繞了好幾天。沒有錯，我一直是個很好的程式開發者，寫得速度不是挺快，不過在問題分析以及結構上很厲害，寫出來的東西簡單明瞭，一看就懂。問題是這樣的才能屬於匠，而非師，把現有的解法做出來並非突破。真正的天才在寫程式這方面是一種由技入藝的領域，能夠跳脫思考，用別人沒想過的方法解決困難的問題。

也就是說，寫程式其實類似藝術。許多人經過訓練可以成為很好的畫匠，可是 Picasso 無法經由訓練產生。

創意才能產生跳躍式的進步，邏輯與分析不能。這些天下來，我領悟到我必須誠實的承認，自己從來不是程式天才，以後也永遠不會是。堅持留在黑手的領域，對於長年學習程式的我來說，的確是塊安穩而舒適的區域，離開需要勇氣。

相對來說，一個讓我困惑不已的問題是：有許多人明知自己是匠，仍然停留在自身領域中。停留著又有什麼不好？以機會成本來說，選擇其他的路子有可能更不符合最大利益，就如同一位室內設計師已經知道了自己不是貝聿銘，這並不表示他不能繼續以此為職。

在台灣 IT 界，技術是最不重要的。

目前心目中重要性的排名：

1. 自我宣傳

舉例：在某些給非專業者以及專業但廢渣者看的雜誌中，寫一些只有非專業者或廢渣會想看的專欄。例如介紹某種在國外早就誰都知道的技術，照本宣科做一次給大家看、把英文網站的東西翻譯一下重講一次，或把 Web 2.0、KM (knowledge management) 還有一大堆三個字或是兩個字簡寫的名詞拿來賣弄一番，告訴你這是下一波的金庫，或這可以幫企業賺／省多少多少錢。重點就是把一些入流者的 common knowledge 拿來當成了不起的東西，舞給不懂的人看。Honestly, 如果你認識很厲害的工程師，會固定把 RUN PC 或是 ITHome 上的技術文章當聖經來看的，請舉手。 Please, ANYONE?

效應：名氣、不懂的人會以為你是專家，所以有需要時會來找你。然後你再包給空有技術但是蠢得只會寫程式的小包就行了。空下來的時間，你可以寫更多的專案成功經驗，更多毫無價值的專欄文章，讓更多人覺得你是大師。

2. 關係、人脈

這不用多說了，這圈子最明顯的問題大概就是「黑」吧。政府案尤烈，民間也不見得好到哪去。當然嘛，由不專業的人負責發案、負責開規格，手上拿的又不是自己的錢，中間可以下手的地方太多了。找個資訊顧問來，更是引狼入室，因為大部分的資訊顧問都屬於 1. 的型，想要他們拿出真正實力幫你評估合身合用的資訊系統？別做夢了，讓你花個幾百萬換來一套資訊化甘苦談，然後再一堆文章討論專案為何失敗、企業如何（花更多錢）避免這樣結果、偶爾成功一次就大張旗鼓上雜誌說某某企業資訊化有成，這樣才能吸引更多人花冤枉錢。

3. 包裝、包裝、包裝！

首先用技巧 1, 2 取得高價，然後雇一大堆三流工程師把所要的系統 hard code 出來，其中還要導入各種專案管理機制，三步一樓五步一閣，用小學除法算出各種達成率等等的百分比，然後把歷史趨勢做成很漂亮的圖表給花錢的冤大頭看。更重要的是必須產生各種文件，一狗票的測試報告每測一輪就全部改幾個字複製一次，還有各種規格說明書，為文務必艱澀難懂，頁數只能多不能少，如此可以確保沒人會認真看，以免「其實並不難，只是我們做爛了」這件事實穿幫。

因為是低價人力 hard code 所以最後當然案子生得出來，不過鐵定過不了關，驗收不過。這時候就可以說，其實案子總是會 delay ，系統分析又那麼難，雙方規格有誤差是難免的。不過既然合約書上只寫明要有飯，但沒指明要煮熟，所以我們沒煮也無可厚非。如今既然規格要增加成飯必須煮熟，我們預估要多花 20% 的時間，以及增加 40% 的預算...

重點：

很少有什麼 IT 專案在技術上是很難的。講句不客氣的，我想一個 POSIX C thread programming 的問題就可以掛掉一狗票 IT programmers. 真正難度通常都在了解需求、需求變動、還有客戶溝通上頭。這意味著以上幾點雖然尖酸刻薄、誇大其詞，但也反映了必然如此的真實。

然而這並不是 IT 先天上本應如此，有太多的理論與實務已經被發展出來克服這些問題，只是如此正規的執行以及學習，門檻太高，還不如去交個回扣，把問題搓掉，大家加減用來得簡單快速。長此以往，大家對 IT 系統產生刻板印象，認為失敗率高、經常不合用、又老是花錢如流水。但資訊化又不能不做，於是只好壓低預算。廠商收入低，於是就做出更不入流的系統、務虛而非務實。我尊敬的一名教授說得好，他說台灣是「地攤式」的做軟體，仔細品味，其言非虛。

最近 HEMiDEMi 成了創業楷模，大家紛紛目為大師，演講分享不斷。我佩服他們的執行，也恭賀他們的成功，以一個工程師的角度，我也讚美「葛力」的技術能力。但，很抱歉，說穿了，這也不過是拿了國外的成功產品進來，依樣畫葫蘆做個台灣版，這跟以前仿冒王國的年代有什麼不同？還有遊戲橘子拿別國的遊戲來賣、Kuro用別人的音樂賺自己的錢、不求長進只炒短線的無名小站，為甚麼現在台面上的儘是這些傢伙？我們難道不能發揮真正網路時代的精神，做出具有原創性的好服務嗎？

這篇文章太重要了。

不入流工程師 | 你在SI 嗎

以接案維生就是會掉入這種循環，我覺得無法避免。關鍵在於其中這段話：

...軟體業中彼此削價競爭，即使你估得準案子成本也搶不到案子(因為估得出成本都太高了，無法在菜市場中競爭)，搶得到的案子也賺不了錢...

沒錯，事實就是如此。總是會有搞不清楚狀況的公司削價競爭，雖然他們最後一定吃屎，但也害到其他的人。意味著這是個微利的紅海市場，以接案為謀生方式的策略是錯誤的。

以上根基於兩原則：

1. 台灣公司接台灣案，不行。印度的 Infosys 收費很高，不過活得不錯，意味著必須接國際大案，而且壓低人力成本才有賺頭。顯然的，專案管理難度極高。
2. 接的是 MIS 類專案，不行。正確的方向是尋找中小型專案，技術難度高而內容少，發包案主最好為科技業廠商。

現階段來看適合的策略是後者。如果繼續接 MIS 案，兩個鐵則：

1. 專案規格已訂死：固定時間，固定金額。任何規格修改，結案後另案進行。
2. 專案規格未訂死：採 agile 開發方式，時間不定，按時收費。

違反以上兩鐵則者，不接。以上是血淚經驗。