爭論點

那天跟公司的研發主管報告專案的程式部份，對我來說要跟別人解釋自己的程式重點我會放在架構，因此我把大多數的時間放在我怎樣使用共用的介面函數指標建立共用的物件（C語言），中間我提到一個東西被轟整場的，我說到～『我的callback function的prototype定義為.....』。

後來這些老大們開始活絡起來（本來好像快睡著的樣子），他們突然開始說『callback function的定義是一定要有signal的事件引發一個function才能叫做callback function』，或許我才疏學淺吧，我怎麼印象中只要使用function pointer指到一特定的函數位置，讓某一機制的程式碼去呼叫這些函數就稱為callback，我印象中跟signal好像沒有直接關係。

不過呢～～爭論一下下我就發現糟糕，因為其實這並不是重點，重點是這是主管要下『指導棋』的時候，所以其實我應該是要說『恩，原來我沒有注意到這麼深的學問』（ㄟ～～吐好看一點啦）。但我覺得很怪的是針對一個程式專案要討論或研究，架構才是重點，但老是把事情放在這種雞毛蒜皮的事情上面，難怪我很討厭開會～～ㄏㄏ。

其實這也是我覺得我們的開發流程有問題的地方，我們一直把焦點放在GUI library上面，也就是大家都在討論～～～哪一個widget可以用、有沒有辦法用更簡單的方式把GUI拉好、顏色怎麼改.....等等，當然我不是說這不重要，只是這些東西在這些GUI論壇或甚至是google一下都可以有解答，但一個程式絕對不是有GUI就完成。（只要GUI不完成任何事的程式不就是示範程式嗎～～ㄏㄏ）

這也讓我想到常常會有人問～～『你對某某library熟不熟』，我常常都不知道怎麼回答，我很少『熟悉』一個library，所以我寫程式一定要有網路，因為我要一直查API的網頁～～ㄏㄏ，但是我發現他們好強歐，用背的耶～～我的天呀。我對SQLite熟不熟～～『恩，我有使用SQL關聯式資料庫的概念，SQLite我知道他是用檔案式的小型資料庫』，這樣的回答基本上我的同事與長官們是會把我當異類的～～ㄏㄏ。

哪些library有哪些API～～我沒有半個熟的，要用的時候我會上網查或甚至把include file打開搜尋一下也可以有個概念，但～～～不論開會的目的是啥，我想應該最終都是要解決問題，因此爭論點是否可以放在『我覺得這樣的架構有....的缺點』、『如果....設計是不是更好』，至於其他展現熟悉度與高深學問的爭議～～我就免了，畢竟～～我本來就不是高材生呀～～ㄏㄏ。

一樣？

以前常常會跟PM吵架，現在大多我已經不吵了，原因大多數是因為工作職權分責。

最近一些軟體專案要開始運作，不過往往負責規劃的人都很會拖，當然我也知道可以把一些基本架構寫好，不過至少要知道這個專案到底要完成哪些工作吧。其實大多數我遇到的狀況都是告知一個很大的框架，然後～～～～工程師應該可以寫了吧。

以前記得有一間公司要做車用資訊系統，規劃的PM很有架式的把工程師叫進去，講了一推CarPC的未來多麼不可限量，然後～～要做啥？我當然知道是車上的資訊系統，只是除非是研發經費無限大、系統能力無限多、研發工程師要多少有多少....不然，還是得有個規劃吧。

以前最常遇到的狀況是～～『阿你不會去看競爭對手有啥功能歐』，其實我很討厭這句話，當然我並不反對參考別人的設計，但那必須是去思考別人的設計用意為何，是否是個適合我們的設計方式，在我們的產品中是否該做如何的轉變。不過～～事實上～～上面的回覆通常是：跟他們一樣就好，比較安全。而且～更讓我奇怪的是，為何這些事情都變成工程師要去想辦法的？

一樣的產品，何必在研發一次呢？當然我知道很多老闆都會用價格來取勝，但除非你偷到別人的設計原始稿會是原始碼，否則很多的東西都是複製表面的狀況，自然～～這類的產品破壞市場的功能多於創造新產品。

現在的狀況其實變化不大，今天總部的PM來討論我對於設計上我覺得不太好用的功能與設計，對方的回答是『你說的其實我都同意，不過競爭對手都是這樣，我們就一樣就好』，一樣～～好吧～～那就一起浮沈吧。

教育券

記得不久之前，在美國舉辦的國際電子元件會議上面，美國的學者呼籲美國政府改善工程師的教育，以免讓美國的工程能力慢慢衰退，其中他們建議要培養T型人材，也就是除了在工程相關領域的研究之外，也要延伸到數學、科學甚至美學的領域，構成一種深入專業領域的廣泛應用人才。當然還有創造力，對於快速以商業力量獲利的美國企業，慢慢的把重心放在商業經營而缺少創新能量。

對照現在政府採取教育券的模式，美國工程界的作法有何不同呢？首先，我們要改善的是基本教育面向，而不是技術。如果你看看這次政府官員在講這個政策，其實很大多數都是採用『技術訓練、快速上工』的思維，當然這凸顯了一個台灣教育體制的問題～～缺少實做精神。但我們應該如何改變這些狀況確實不應該由『技術訓練』著手，對於學校教育中能夠加強的應該是實際的應用思考。

簡單來說，當我們在學校學習許多的電腦程式演算法的時候，老師常常講解理論，然後把重點放在每個演算法的效能評估上面（就是big-O函數～～ㄏㄏ），當然這應該要了解，只是問題在於除了這一個部份，現有這麼多學習的演算法，有哪些地方可以用到老師從來不講解。當這些學生出了社會，赫然發現許許多多的任務要去解決，但～～～不知如何下手。

當然我們的工程師還有一個大問題也跟美國一樣，我們往往太過於專注於自己的領域，例如～～一個軟體工程師只對程式語言的議題感到興趣，其他的學識往往都一無興趣。但假設今天出現一個工作，希望工程師去完成一個應用程式，重點不在於軟體怎麼寫，而在於～～這個軟體怎麼運作，其中涉及的不是程式語言的範疇，而是～～～這個應該程式的know-how。

工作中常常遇到一些學校剛畢業的學生，在學校的時候成績一把罩，但當面對一個沒有標準答案的工作任務～～～往往傻眼不知如何下手，他們常常需要你告訴他們怎麼開始寫，其實很多東西學校都有教過，只是不知道為何當面對到的時候，一定要有人跟他們說『這裡應該可以用liXXXXXnked list解決』『scanline演算法可以處理這一段』...，我覺得如何把學生所學的東西實際貫通才是最為重要的。

台灣的科技產業歷經了大量代工的年代，因此很多優秀的畢業生，一畢業之後進到大公司往往就是開始做一些機械性重複的動作，這些優秀的學生在歷經多年這樣的職場訓練，往往也喪失了邏輯的處理能力。記得多年前有學者呼籲企業界讓員工開始創新，否則台灣的資訊產業將停留在代工、製程改善的死胡同。或許這才是目前台灣科技產業最大的問題，為何大量裁撤掉工程師，因為～～～這些工程師對公司來說只是螺絲釘，具有標準規格，之後在買就好，這樣子代工模式思維其實大量存在我們許多科技產業。

因此，如果要解決高學歷失業的問題，如何改變科技產業結構比讓畢業生重新受技能訓練重要，畢竟要讓市場上產生高學歷學生的需求比改變這些學生去符合現在產業來的長遠。其實現在高學歷失業的問題也凸顯一個有趣的問題是，我們這個社會真的需要這麼多大學生嗎？或是說需要這麼多科技相關領域的高知識份子？資訊產業對於台灣來說有一種磁吸作用，它往往讓其他較有未來的產業的社會資源被排擠，所以或許少一些資訊博士，多一些文化博士、音樂人才、農業專家.....會對這個社會產生比較正面的改變。

與其花許多的錢發放教育券，我倒是覺得認真思考我們的教育政策來的充實些。