MaoYang 兄看到我分享〈技術經理的教練角色〉之後，他在噗浪河道上回應他對我文章觀點的看法。他說：
我常在做的 『教練』 工作大部分是在講一些基礎的東西與衍生的技術, 但是倒沒有想過要將團隊變成 『一致性』 , 試想, 你身為經理確發現實作的工程師缺乏某些觀念時, 你不得不著急,但是這種狀況出來的時候, 產品也開始出現許多問題, 這是技術經理面臨最大的挑戰。但是當技術經理開始當 『教練』 已經離開工程師角色一段時間, 這又是另一個挑戰
同人很高興 MaoYang 能夠針對這個主題提出討論。對於他所提到的問題，我常看到的是技術經理不能因材施教，所以究竟來看也是身為教練本身指導的彈性不足，也是多樣性的問題，尤其在軟體開發專案更為常見。
而且有時候工程師不是不懂那些概念，而是他們碰到一些技術經理不重視或忽略的問題，但如果沒辦法幫他們解決那些問題，如何讓他們接受那些觀念。教練就只會流於說教的自說自話。 Read the rest of this entry »
今天是 2009 年的最後一天。計劃未來一直不是同人擅長的項目，隨性的個性也讓我不喜歡依照目標來做事，喜歡把重點放在當下。然而，最近在回顧這一年的經歷卻感受到，在 2009 年的最後一天，很想寫下自己對來年努力方向的期望。
2009 年對同人來說，是「清理過去」的一年。 Read the rest of this entry »
在噗浪的河道上看到 MaoYang 兄提到技術經理做好教練角色的困難。他說：
技術經理有時候要扮演 『教練』 的角色, 這時候要將正確的觀念傳遞, 這是有點困難的, 因為往往會被自己的極限所限制, 想起了一位朋友,他是長笛老師, 他說他知道那個音要如何如何才是完美的, 但是他確無法示範出來
對於 MaoYang 兄的觀點，通達人認為 MaoYang 的朋友應該要學如何示範，不然就不是個夠格的老師。這代表了技術經理應該要學習如何正確示範，否則就不能算是個好教練。MaoYang 兄進一步解釋他對技術經理擔任教練角色的觀察：
在公司內部, 技術經理當 『教練』 並不是明定的工作, 但是當團隊的程度良莠不齊的時候, 技術經理帶頭出來當 『教練』 , 是不得不的, 但是技術經理有時當管理職太久, 要把許多實作交代清楚, 這是當技術經理累人的地方
以上的解釋，通達人認為他同意當「教練」並不是技術經理明定的工作，但為了要避免身為技術經理的時間都被部屬瓜分了，較佳的方案還是當教練，讓部屬有成長的機會和空間。另外，有一位噗友 Daniel Li 也認為，身為技術領導者，給部屬魚吃不如教他如何釣魚。因為總是有一天，他們會離開教練單飛，就像教小孩走路；我們不可能一直挨著他隨時扶著他，只能教他方法、鼓勵或強迫他嘗試，並獎勵或誇大他的小成功。
在觀念上，以上的討論已經將技術經理擔任教練的動機及基本觀念，詮釋地相當清楚。但從自己實際從事技術工作的經驗來看技術經理當教練這件事，事情卻好像並不如以上討論到的那麼簡單。同人認為 MaoYang 兄提到的這個主題，可以從兩方面來探討，一個是技術經理要教練的東西為何，另一個則是技術經理擔任教練的目的為何。 Read the rest of this entry »
去年同人寫下〈從海砂屋陰影學到的教訓〉，分享我們全家陷入海砂屋陰影的經驗，並提供同人從此事件得到的教訓與心得。原來這篇文章的寫作動機，只是想提醒想要購屋的朋友要小心資訊不對稱的現象，不要隨便聽信仲介的說辭而陷入對買方不公平的交易陷阱。但這一年來，看到很多朋友都是發現買到海砂屋之後，才看到同人的文章。從文章的留言與 email 的詢問中，關心最多的應該就是詢問存證信函該如何寫的問題，這似乎提醒我應該再寫一篇文章來分享存證信函該怎麼寫，來爭取買方的權益。
同人先提供當時我所寫的版本如下 Read the rest of this entry »
在河道上看到噗友分享「認識自己的＜西洋星座命盤＞」，它是轉貼自網路上的資訊，內容提到星體與上昇星座在占星盤中所代表的意涵。其中在月亮星座的部分，有下面這一段話。
月亮：主導潛在的特質,遇到突發狀況的立即反應！月亮星座很重要，是指情緒、第一時間的反應… 比如說當你的車子被人撞凹了，第一時間反應是打人還是報警？是看月亮星座…
同人直覺到上面這段話有問題。就我所知道的占星學觀念，月亮星座的確和突然狀況的立即反應有關，是代表情緒反應沒錯，但這種反應是否就是一般人所認知的第一時間的反應？同人認為這是很有問題的。然後，我又看到車子被撞凹後的行為反應是看月亮星座，這顯然並不是精確的說法，而是有以月亮星座簡化性格之嫌。
其實月亮星座的反應僅限於內心情感的情緒層面，而不會讓命盤主採取行動。或者用更精確的說法是，命盤主會選擇用行為來處理他的情緒反應，是因為其它星體的性格而非月亮星座。 Read the rest of this entry »
石頭成在〈與 metavige 和 alexchen 對話 Java 語言〉這篇文章中，直言他對 Java 語言泛型的批評：
我不認為 Java 讓我們「慢工出細活」，我覺得它帶來的是「冗餘的複雜性」。就算以 C++ 的觀點來看 Java 程式碼，我仍覺得 Java 程式碼有許多不必要的複雜度。Java 把類別變成施加在程序員身上的束縛，而是不是幫助我們進行抽象化資料處理的工具。
我個人認為，所謂「更強化的靜態型態」是跟 C++ 樣板相比， Java 泛型比起 C++ 樣板是在走回頭路。就我到目前為止的 Java 使用經驗來看，我幾乎以為泛型只是 Java 專門用來重新設計容器類別的特殊語法。在那以外的場所，你大概不會想用泛型來重構你的程式碼。
metavige 就說會想用 Strategy Pattern 來重構我在〈從 C++ Template 到 Java Generic，一步一步來〉舉的例子，而不會用泛型。但是泛型難道不是用來處理這個問題的直覺想法嗎？ Java 沒有足夠理由說服我們不要用泛型來做，但是用泛型來做… 呃，似乎更困難。
石頭成用泛型來重構程式碼，是不是處理他的問題之直覺想法？我想石頭成比較偏好動態型態語言的自由，比較不欣賞「更強化的靜態型態」的做法。或許是因為 C++ 用 template 實作不會受到參數型別類型的限制，自然會讓他比較想用泛型來重構程式，以去除資料型態與演算邏輯的相依性。然而，看過石頭成所舉的實例，同人認為用泛型來實作的想法未必是直覺的做法。
表面上看起來好像實作泛型可以讓某一段程式碼重複使用，但 Java 在泛型的限制，也增加他重構程式碼的困難度與複雜度。這麼說來，假如石頭成的想法是正確的，用 Java 的泛型來重構程式碼，只會讓程式員沒事自討苦吃。然而，同人在仔細研究他的程式碼之後，發現可以用更簡潔的方式來使用 Java 的泛型。不過，還是讓我們先來看看石頭成的程式碼： Read the rest of this entry »
