在人際溝通的過程中，我們聆聽他人的意見，並發表我們對他們意見的看法。不過，在彼此間充滿著歧見及情緒反應的討論中，我們常常無法靜下心來傾聽對方所要傳達的訊息。於是在聽從主觀的思想而忘卻聽從內心的客觀分析的狀態下，結果讓我們聽到的都是我們想要聽的部分，卻把不想聽的部分刻意忽略掉。
《深度匯談》作者威廉．伊薩克認為，我們的想法往往是基於過去經驗對現在情境所形成的推論，它並不是事實，事實是可以透過直接觀察得來的，而不是按照過去經驗推論而來的，這樣會造成個人的偏見。在對話過程中，我們必須堅持事實，依據過去經驗而做推論並不是思考，而是對回憶的反應。所以我們必須能將「依據經驗所做的推論」與經驗本身區分清楚，而書中提到了「推論之梯」，就是可以達成這個目的的工具。 閱讀全文
我們通常會用「工程師性格」來形容那些不擅人際交往，卻能專注於某些專業技術領域的人。大部分的人認為工程師的理性多於感性，這種人雖然缺少生活情趣，不大會與人溝通；但他們實事求是、崇本務實的精神，卻是默默地問題解決者。最近同人向一位朋友提到，我對他印象中認為服務態度不錯的客服人員對我的服務態度覺得很不以為然，因為那位客服人員堅持他們的系統沒有問題，卻沒有了解為什麼我使用上會出狀況，我認為這個客服人員根本就沒弄清楚狀況，就急著斷言他們的客戶使用上沒這個問題，但難道我不是他們的客戶嗎？朋友認為，那位客服人員的反應是工程師性格的表現，所以他認為他還可以接受這種狀況。
先不管那位客服人員是否有工程師性格，同人在比對了朋友在使用相同系統所使用的操作環境後，馬上發現問題所在，該系統並未考慮 Firefox 的瀏覽器，而恰好我是透過 Firefox 來使用系統，於是造成中文的編碼問題，用 IE Tab 就很輕易地解決這個問題。
解決了我的問題後，同人向朋友表示，個人不喜歡這種工程師性格，我認為真正的工程師都會探究問題找答案。不過，朋友對此提出了不一樣的看法。他認為我要先思考一個問題，是否我也是有工程師性格，一般而言，這樣很容易與對方發生衝突。
閱讀全文
在我們周遭人的看法與意見，常會在不知不覺地影響我們的觀點，使我們看不清楚事物的本質。最近同人和朋友在 MSN 聊到工作價值觀的問題，朋友告訴我，他最近很感嘆他們公司的文化，也就是什麼都能做，而且要立刻去做。雖然從一方面來看，Just do it，表現了處事的積極態度，但在另一方面，他也深深地感受到，公司有些人都不太想一想，事情的道理在哪裡。
朋友的觀點，突然讓我發現，從最近他的經驗分享及我們所聊到的話題中，好像都與組織學習有某些關聯。對於我的這個發現，他表示最近他剛好在讀《第五項修煉》，同時他和他的同事組了讀書會。我問他：＂是否開始質疑身邊理所當然之事？＂。他回答道：＂有一點吧，最近常和同事討論，交換心得更有啟發＂。
我記得之前曾向這位朋友分享過一個感覺，就是在我追求學習與成長的過程中，很容易會接受到更多元的資訊與知識，無形中會擴展自己視野，但卻也會逐漸體會到自己會開始不習慣以前所習以為常的觀念，因為我擁有更多的資訊與知識去審視它們，不再像過去那樣地全盤吸收一般人所認定的傳統觀念。然而，挑戰傳統觀念的結果，卻很容易產生與上司的理念之爭。因此，這次與朋友的這段對話，讓我心中產生了一種想法，個人的成長與改變似乎很容易與周遭人事物產生格格不入的現象，這讓我想到了「洞穴寓言」的隱喻。
閱讀全文
在 OO 社群中，由人稱 GoF 所著的《design Patterns: Elements of Reusable Object-Oriented Software》中文版為由葉秉哲譯（2001），《物件導向設計模式》，美商普林帝斯霍爾國際出版。被認為是物件導向軟體設計的重要典範，但最近在 InfoQ中文站，有一篇文章的主題是 〈InfoQ: “四人帮”的设计模式经得起时间的考验么？〉，提到這本書最近被人質疑已經與時代的發展脫節，書中解決問題的方式已經可以由新的語言來做更好的處理，用書中的設計樣式有關 design pattern 一詞，中文有兩種翻譯方式，設計模式與設計樣式，同人習慣用「設計樣式」來稱呼之。來解決設計問題還會增加不必要的複雜度。
這篇文章提到對設計樣式的反面意見主要包括了設計樣式是一種複雜性的表現形式、對設計樣式的樣板式代碼（boilerplate code）的需要，代表在設計思路上的問題，也就是開發者所使用的語言基礎結構出現問題的信號、以及設計樣式阻礙了《A Pattern Language – Towns, Buildings, Construction》這本建築架構思想的傳播，本書是被公認是激發了資訊科學領域內的設計樣式運動。
閱讀全文
同人先聲明，本篇文章不談高鐵，而是從我所寫的〈從高鐵談大型公共建設軟體開發專案〉的上下篇的讀者迴響中，發現有一些值得探討的議題，在此做個整理。
有讀者提到，大型公共建設軟體開發專案要讓大部分的人滿意，需要整體的合作與共識，所以他認為”分包委外服務提供者”既然受人之託，就要忠人之事，若能做到的話，相信”做好關係人管理，達到同時兼顧所有關係人的期待”將不會是一項挑戰。
對於這個看法，同人在情感上認同”受人之託，就要忠人之事，就可以做好關係人管理”，但在理智及經驗上，卻往往發現我們事情往往出乎我們意料之外。為什麼呢？人的問題實在複雜得超乎我們原先預期，除了資訊不對稱之外，利益的不相容所造成的代理問題外，還有對方是否值得信任的風險考量，背景與專業所造成的溝通困難等，都讓做好關係人管理這件事，充滿了變數，這對參與軟體開發實務管理者及開發者而言，是如人飲水，冷暖自知的呀。
閱讀全文
如果當你聽到了「三百公斤的豬，是不是一頭肥豬？」，隨即出現莞爾一笑時，我會猜測你多半聽過楊維寧老師教授過的統計學課程。這句話實在太經典了，先不管統計學得好不好，這句話讓人印象深刻，並領悟到統計學與生活可以如此貼近。事實上，只我們在生活中願意去思考，統計學的應用並沒有想像中的難，重點在於思考，而非繁複的理論與計算，這也是一種「百姓日用而不知」[ref]《易經．繫辭上》：仁者見之謂仁，智者見之謂之智，百姓日用而不知。[/ref]。
「三百公斤的豬，是不是一頭肥豬？」，答案並不重要，重要的是解答這問題的過程。要解答這個問題，我們必須要對所有豬的群體有所理解，所以我們有興趣的是豬的母體，如果我們知道所有豬的群體的重量機率分配，也就是掌握了豬的重量在統計學上的平均值與標準差，那麼我們自然會知道任何一頭豬是肥豬或是瘦豬。
不過，在真實世界中，我們不大可能找到所有的豬，然後去量測牠們的重量並算出平均值與標準差。因為人力與成本的限制，我們無法知道母體的實際狀況，取而代之的是以抽樣的方式來解決我們的困境，以樣本來推論母體，我們隨機抽樣找了足以滿足中央極限定理的豬群來當樣本，以樣本的平均統計量來推論母體的平均值，以樣本的標準誤統計量來推論母體的標準差。
所以，那頭三百公斤的豬是肥豬或瘦豬呢？運用假設檢定，如果我們能夠拒絕三百公斤的豬不是肥豬的虛無假設，也就是假設三百公斤並未顯著地小於等於樣本的平均值統計量，那麼這頭豬就是肥豬，否則牠就不是肥豬。
利用豬的重量去理解假設檢定的概念其實並不困難，但要深入思考才能理解精髓所在，而不是靠背公式或憑一己印象或好惡判斷來解決問題。人們習慣於憑直覺或第一印象來看事情，但肉眼不能看見事物的精髓，唯有用心才能分辨事物的價值[ref]宋碧雲譯（1992），《小王子》，志文出版。[/ref]。一如在〈從高鐵談大型公共建設軟體開發專案（下）〉的讀者回應中，同人發現大家的談論焦點己背離文章所要表達的主題，情緒波動已使大家流於沒有意義的爭論之中，實在是相當可惜。
閱讀全文
我們對於他人不同觀點的反應，關係著個人認知的品質。在多元化的環境當中，每個人都可以擁有不同的主張與信念，而站在個人的學習成長的角度而言，個人的本位主義常常會讓我們看不清楚個人的盲點，排斥與我們主張不一樣的觀點往往是讓我們無法進一步成長的最大障礙。
有時候，對方不一樣的看法對我們而言其實是可以帶來創造力的。當然，每個人都是具有獨特性的創造者，不該妄自菲薄，但對於我們身邊的事件，我們應該留心觀察，並加以思考事件的意義。
當然我們可以選擇抗拒，繼續當井蛙、夏蟲以及曲士莊子/秋水. (2007, 4月 29). Wikisource, . Retrieved 02:49, 8月 6, 2007.，但我們真正抗拒到的是自己的成長，假想敵從來都未曾存在過同人在此引述《奇蹟課程》的觀念：凡不真實的，根本就不存在。假想敵是我們虛構的人事物，為了發洩我們負面情緒的投射物，所以它從來都未曾存在過。。「不得於言，勿求其心」的態度，認為他人的言語不中聽，就不去探求別人內心想表達的事物，其實是屈解「不動心」的「未嘗知義」四書章句集註/孟子集註卷三. (2007, 5月 22). Wikisource, . Retrieved 03:06, 8月 6, 2007.呀。
閱讀全文
本文係投稿於 CNet / ZDNet Taiwan 的上下兩篇文章初稿，未經 ZDNet Taiwan 編輯，其內容可能會略有差異。
這篇文章引來不少爭議，有人認為同人是在為某些組織消毒，所以把同人當人假想敵，而有些情緒性的言詞批評與指責。也有人認為同人說高鐵售票系統未用資料庫技術就是問題所在，以為高鐵售票系統的問題就是迷信新技術。還有人認為，技術才是解決問題的關鍵，要用技術的角度來思考問題才是標準答案。
對於這些意見，同人認為別人的情緒是他的問題，我會寫那篇文章，並不想為誰辯駁，只是提出個人思考的觀點，所以要把同人當成假想敵，想激怒我，本人可沒那麼容易上當。至於看到迷信新技術的推論，實在令人大開眼界，不幸地，這個推論顯然是錯誤的，這就是只會用技術看事情的迷思呀。至於要用技術觀點來思考問題的意見，同人覺得再解釋都顯得多餘了，過去我已談過太多了，碰到沒問題症候群（Gerald M. Weinberg，1986）的患者，這次我選擇躲遠點，明哲保身呀;^)。
以下就是這篇引來不少意見之文章。
高鐵售票系統在上線後產生一連串的問題，除了媒體不斷地報導外，網路上也引起熱烈的討論。其中批評與指責多過讚美，同人對這些意見的感想是「外行人看熱鬧，內行人看門道」。我們是否能從他人的失敗經驗得到些許啟示；還是跟著湊熱鬧，把它當成茶餘飯後的話題，是很值得深思的問題。
閱讀全文
最近 ZDNet Taiwan 為同人開闢了「軟體開發見聞錄」的專欄，並將我所寫的〈從高鐵售票系統談大型公共建設軟體開發專案〉，分上下兩篇在此專欄發表。和上次我投稿的〈羅馬不是一天造成的〉比較起來，本篇文章引起了一些讀者的迴響，從這些讀者的評論看起來，似乎「高鐵售票系統」比較容易讓人感到敏感，而對我的文章有所指教。在看了這些對軟體開發見聞錄首部曲的意見，不禁讓同人深刻地感受到，態度實在是決定我們是否能深入思考問題的一大關鍵呀。
有讀者認為，大型公共建設軟體開發專案要讓大部分的人滿意，需要整體的合作與共識，例如”分包委外服務提供者”既然受人之託，就要忠人之事，若能做到的話，相信”做好關係人管理，達到同時兼顧所有關係人的期待”將不會是一項挑戰。
對於這個意見同人的看法是，在情感上，我認同”受人之託，就要忠人之事，就可以做好關係人管理”，但在理智及經驗上，卻往往發現事情往往會出乎我們意料之外。為什麼呢？人的問題太複雜了，除了資訊不對稱、利益的不相容所造成的代理問題外，還會有對方是否值得信任的風險決策、服務需求者與提供者雙方背景與專業的落差所造成的溝通困難等，都讓做好關係人管理這件事，充滿了變數，相信在實務上，對於參與過大型軟體開發管理者及開發者而言，以上是如人飲水，冷暖自知的呀。
閱讀全文
前文提到在查詢永續物件的後端實作上，在處理 where 條件式的部分，對於物件查詢的樹狀結構條件表示式而言，可以運用 GOF 的 interpreter pattern 的觀念，藉由尋訪語法樹的過程中來予以解析同時加以處理。
但在實作的考量上，相同的條件表示式在解析處理上卻必須隨著採用的永續框架而有所變化。因此，解析處理的實作並不能放在 QueryExpression 中，而是必須將解析處理的概念封裝為尋訪器的界面，讓 QueryExpression 可接受不同尋訪器，以容納可針對採用不同永續框架而有不同解析處理的功能。
此種做法其實就是利用 GOF 的 visitor pattern 來增加系統設計的彈性，但限於篇幅，前文並未交待要如何做，本文就是要接續這個問題來做後續探討。首先，我們定義用來解析處理樹狀結構之條件表示式的尋訪器界面，即 QueryExpressionVistior，它知道如何尋訪條件表示式中的各種資料型態。然後讓 QueryExpression 可以接受不同的尋訪器來解析處理條件表示式：
閱讀全文
