2015年寫的文章，可能忽然想到什麼，寫了很多工作回顧，現在終於有機會浮出水面!
圖文不符。
最近網路上流行一篇文章10年程設夢, 人老了最大的特徵就是喜歡回億, 好漢不提當年勇, 就怕人不知, 不過人生有幾個十年, 一轉眼, 我在這個鮮為人知的領域已經15年. 這15年, 幾乎就像浮萍一樣, 隨著風, 隨著水的流動, 有過感動, 有過沮喪, 有過成功的案子, 有過失敗的案子, 除了一段時間不務正業的當了幕僚, 幾乎都和軟韌體程式脫離不了關係.
比較奇怪的是, 我從來沒有下定目標要當一個工程師, 甚至沒有立誓斬雞頭灑雞血要一直寫軟體, 有的是一直對電腦這檔事情一直存在著興趣, 新的技術或產品是唯一能讓我眼睛稍為睜大一點的事物.
有blog的好處就是, 不需要投稿, 不需要評審, 隨時可以寫, 隨時可以置頂.
還有這一段回憶錄都沒有談到人的部分, 只有技術上的起起伏伏, 但偏偏人是最關鍵的因素, 永遠感恩幫過我, push過我的人, co-work過的人, 你知道我在說你....
然後這一系列是寫給你我看的, 我怕哪天老人癡呆了, 想要臭屁會連草稿都沒有...
時間拉回十年前...
第一份工作, 和我房間裡的照片有關, 照片讓大家失望了, 不是酒井法子, 不是工藤靜香, 不是飯島.. ,是買柯志賢有關主機版的書所送的ㄧ張486主機版的構照圖, 我常常看著這張圖想像著這一座小城市裡面到底是在運作甚麼? 畢業後有機會拿到HP PM的offer(出一張嘴的工作和我一直很有緣份)和一線board廠的offer, 完全沒有考慮下意識的選擇後者, 後來我常想, 當年的ㄧ個衝動, 其實有可能就是一輩子.
當時面試我的主管希望我寫測試程式幫忙HW debug, 讓測試可以自動化, 在寫在公司的第一支程式之前, 我的程式通常是自用, 也就是自己定spec, 自己想 UI, 自己設計algorithm, 拿來交作業, 拿來給論文當implement, 而且是純軟體. 但是因為公司屬性, 在我進公司的前幾個月, K第一本PCI Spec就嚇壞我了, 不只如同天書般的英文(非英文系國家的英文), 還有完全不懂的background, 就這樣我幾乎四周都是牆的黑巷裡面度過快半年, 結果是一知半解, 一支程式也寫不出來.
因緣際會裡, 公司有一個訓練課程講 Linux, 讓我回憶到讀書時常用的Unix(玩mud, 算UNIX經驗??), 又因緣際會公司需要一個Linux下HDD的測試程式, 所以我就將Linux Shell上面的command兜一兜, 丟給大家測試了, 當時真是有一股虛榮感, 一來大多測試程式大多是Windows base的, 二來公司測試單位拿到自己公司內部生產出來的測試程式都很興奮, 害我高興的很多天睡不著.
沒多久就證明沒實力的燦爛如同煙火都不會太久, 原因在於我是為了創造程式而寫, 測試部門需要在有錯誤時, 有清楚的訊息知道有沒有error? HW需要知到error在哪裡? 才有機會debug, 所以我的程式只能在HDD健康時跑, 有問題的HDD也測不出結果, 真是尷尬, 當我想再往下層寫去, 發現層層阻礙.
這個第一隻程式是失敗的, 讓我發現要"給大家用"的程式需要收集requirement, 需要軟體spec, 並不是一頭栽下去寫, 寫興趣的, 不然寫不出真正有用的程式, 反而會造成天下大亂. 這一點其實尷尬, 自己Master讀軟體工程, 到了要工作時, 剛好把自己所有該會的東西都忘掉, 所以學以致用真的是最最最最難的ㄧ課, 象牙塔裡的東西如果不能做成象牙都很不值錢.
比較奇怪的是, 我從來沒有下定目標要當一個工程師, 甚至沒有立誓斬雞頭灑雞血要一直寫軟體, 有的是一直對電腦這檔事情一直存在著興趣, 新的技術或產品是唯一能讓我眼睛稍為睜大一點的事物.
有blog的好處就是, 不需要投稿, 不需要評審, 隨時可以寫, 隨時可以置頂.
還有這一段回憶錄都沒有談到人的部分, 只有技術上的起起伏伏, 但偏偏人是最關鍵的因素, 永遠感恩幫過我, push過我的人, co-work過的人, 你知道我在說你....
然後這一系列是寫給你我看的, 我怕哪天老人癡呆了, 想要臭屁會連草稿都沒有...
時間拉回十年前...
第一份工作, 和我房間裡的照片有關, 照片讓大家失望了, 不是酒井法子, 不是工藤靜香, 不是飯島.. ,是買柯志賢有關主機版的書所送的ㄧ張486主機版的構照圖, 我常常看著這張圖想像著這一座小城市裡面到底是在運作甚麼? 畢業後有機會拿到HP PM的offer(出一張嘴的工作和我一直很有緣份)和一線board廠的offer, 完全沒有考慮下意識的選擇後者, 後來我常想, 當年的ㄧ個衝動, 其實有可能就是一輩子.
當時面試我的主管希望我寫測試程式幫忙HW debug, 讓測試可以自動化, 在寫在公司的第一支程式之前, 我的程式通常是自用, 也就是自己定spec, 自己想 UI, 自己設計algorithm, 拿來交作業, 拿來給論文當implement, 而且是純軟體. 但是因為公司屬性, 在我進公司的前幾個月, K第一本PCI Spec就嚇壞我了, 不只如同天書般的英文(非英文系國家的英文), 還有完全不懂的background, 就這樣我幾乎四周都是牆的黑巷裡面度過快半年, 結果是一知半解, 一支程式也寫不出來.
因緣際會裡, 公司有一個訓練課程講 Linux, 讓我回憶到讀書時常用的Unix(玩mud, 算UNIX經驗??), 又因緣際會公司需要一個Linux下HDD的測試程式, 所以我就將Linux Shell上面的command兜一兜, 丟給大家測試了, 當時真是有一股虛榮感, 一來大多測試程式大多是Windows base的, 二來公司測試單位拿到自己公司內部生產出來的測試程式都很興奮, 害我高興的很多天睡不著.
沒多久就證明沒實力的燦爛如同煙火都不會太久, 原因在於我是為了創造程式而寫, 測試部門需要在有錯誤時, 有清楚的訊息知道有沒有error? HW需要知到error在哪裡? 才有機會debug, 所以我的程式只能在HDD健康時跑, 有問題的HDD也測不出結果, 真是尷尬, 當我想再往下層寫去, 發現層層阻礙.
這個第一隻程式是失敗的, 讓我發現要"給大家用"的程式需要收集requirement, 需要軟體spec, 並不是一頭栽下去寫, 寫興趣的, 不然寫不出真正有用的程式, 反而會造成天下大亂. 這一點其實尷尬, 自己Master讀軟體工程, 到了要工作時, 剛好把自己所有該會的東西都忘掉, 所以學以致用真的是最最最最難的ㄧ課, 象牙塔裡的東西如果不能做成象牙都很不值錢.
因緣際會有機會碰到當時正在成長中的windows smartphone, JAVA在那個時間點, 其實還算有一點小紅, 一些比較好的feature phone都有可以跑JAVA程式的KVM, JAVA在手持系統上的架構力推J2ME, 其實J2ME的想法和現在當紅的iPhone app根本是同一回事, 只是論技術J2ME可能沒有輸人, 但論到包裝技術, 老賈應該當今世上第一把.
當時架構在smartphone上面的是third party一家廠商insignia, insignia很積極想推VM到smartphone上面, 還好讀書時, 寫過幾行JAVA, J2ME還算好懂, 所以寫了幾個測試KVM效能的小APP, 無意中寫到關於中文字時, 發現KVM對中文的支援很差, 跟insignia FAE討論後, FAE就逃之夭夭了, 不過比較振奮的是, JAVA當時候的三塊大餅, 我吃了兩塊分別是J2SE和J2ME, J2EE就沒有這樣的好運氣, 一直沒有機會摸摸.
在那個時間點, 其實我是認為KVM是大有可為的, 因為它可以在任何的手機平台上執行run anywhere的應用程式,如果那時候 KVM有起來, 現在應該就不會有Android 和iOS之爭了, 回頭再看KVM, JAVA的理念其實對於這個世界的科技是正面的, 只是沒有"能人"知道如何包裝和推動這些技術到使用者手上, 這些工作更是難以讓專門生產硬體的公司來落實. 不過話又說回來, 老賈也是從這幾年的失敗經驗中才讓iPhone一炮而紅.
那段期間, 老實說並沒有很大的案子壓力, 手上有兩隻老大丟給我的最新Nokia和SE手機, 還有一支MS Samrtphone, 每天都沉溺在測試這三隻手機上,每天都等天亮, 急著衝去上班, 其間下載了無數APP和spec, 看了好多手機評比, 甚至還review某家印度軟體公司的app, 只能說這份工作真的是做興趣的, 但是通常有給薪的爽日子都不會太久...
沒多久, 終於有機會看到Windows Mobile(WM)的source, 當時候我對WM的source只能說"非常困惑"來形容, 無窮無盡很虛的API, 還有其實最關鍵是了不了解OS, 我又回去翻了恐龍書, 常常為了看懂一段code, 花了一個小時, 結果還是不解, 但是就是那個時候養成看Windows SDK的習慣, 雖然那段期間甚麼鳥蛋都沒有產出, 但是對我日後寫driver或是app其實影響很大. 也因為這個時候, 發現Windows不是想像中的可惡, 對programmer而言, Windows提供的很多有用的文件, 甚至對我來說印證了恐龍書上的大部分concept.
WM其實還有一塊boot loader, 我當時候的組語功力mov 還會寫成move, 為了瞭解那些完全不懂的code, 全部印了出來, 還好不是太長, 如果是 BIOS還真印不完, 第一次看到boot loader, 終於體會到這真是個令人沮喪的灰色人生, 我幾乎是逐行翻譯每一行code, 過幾年才發現那時候看得那麼苦, 就是沒有拿spec好好對照, 甚至應該還有boot loader的procedure, 蠻幹是行不通的, 資源到手, 才會一路順暢. 還有一點, 當你天資沒有人家聰潁時, 蠻幹硬上更是行不通.
那時候有機會見識到在這個軟體領域有所成的RD前輩, 每一個人幾乎都有所長, 而且把持著自己的成功軟體, 在內部技術會議上侃侃而談, 原來RD和軟體比我想像中還要重要也是那時候在我心中萌芽的.
我曾經看過很多工程師很想做 BIOS, 甚至我還認識非BIOS不做的兄弟, 當然堅持是人和其他動物不一樣的地方, 但是我問他為何要做BIOS, 他只回答我門檻高, 當你token 0改1, 解掉一個bug, 請問門檻在哪裡? 不過那時候, 不知不覺也開始我BIOS的人生, 也許真的門檻高, 讓我這幾年一直為BIOS效力, 不過細說從頭, 有一個不是很順利的開始.
做第一個BIOS案子時, 我對看offset和register薄弱到一個幼幼班程度, 當時候也很認真的從reset vector開始trace, AMI的code據說是call routine比較少的, 當時候我還是吃足苦頭, 常常一個routine, trace到最後迷路.
還有..當時還對Windows的東西無法忘懷, 組語從來沒認真練過, 幸好有人扛起那個案子也不致於太累, 但是"成就感"低到一個地步, 很好笑的是以肉腳來說竟然要用"成就感"來衡量自己的工作, 所以十年前就有草莓族了, 不是現在才有..那時候, 只能說對做 BIOS完全沒有 FU, 做事情還是需要FU這檔事情的.
有一天發現同事在改SM BUS的driver, 無意中我喵了兩三下, 果然有一見如故的感覺, 同樣是寫register, FU怎麼會這麼好, 這不就是我一心想做的事情嗎? 當場share過來做..
其實這支SM BUS的底層程式真正開啟我的眼界, 因為作業系統從98後都有保護模式, 不能直接寫IC register, 很多和h/w有關的事情根本不能做, 軟體無法發揮應有功能. 之後的好幾個月, 我又開始沉溺在如何在作業系統底下讀寫register. 這支程式當時我幾乎是每天看, 回到家還是看, 幾乎背下整支程式.
沒多久我才知道這個程式只是DLL, 他是被另一個 APP呼叫, 這兩個程式合體, 才有化學變化, 沒多久這個 APP終於入手, 其實在這之前我都是用MS提供的Visual Studio IDE, VS K了一段時間為了跟上一個公司的老案子, 又為了MFC K了侯捷的書好一段時間, 但是我拿到的這個APP竟然是Borland C++ Builder(BCB)寫的, 找了一本BCB的書K了幾頁就開始上手, 這個程式裡, 我最喜歡的就是"程式幾乎是從頭開始打造", 那種萬丈高樓平地起的擁有感很踏實, 如果有其他copy來的就是有一段"多邊型UI"的code, 這段code也是我唯一我看不懂的部分, 原來這一段是windows native API, 找來 MSDN努力的 search.
後來我們BCB的環境update, 我順手把多邊型UI改寫成 DLL, 讓他適用在各種不同版本的IDE, 之後產品的多邊型 UI都是用這支DLL. 在那個時間點, 我一直認為硬體底層的讀寫是最困難的, 後來才了解真正的學問在 UI, 硬體的底層只要有 template, 有固定的機制讀寫 register, 但是真的令人傷透腦筋的是UI, 研究所時所修的Human Factor完全壓垮在象牙塔中, 有點像拿Lamborghini V12硬要裝在Toyota上面的那種無奈, 哪來有時間去field research我icon要放哪裡? 用bar好還是用item好?
UI的感受其實見仁見智, 但是之前在手持裝置上的使用經驗, 搞得我越來越龜毛, 手持的 UI和當時的桌面軟體比其實精緻很多, PC上軟體UI樣式一直被MS控制, MS的UI的想法應該只有一點, 就是教育end user, 讓大家接受我們的 UI, 然後擺脫不了他, 但是真正的 UI其實應該不需要任何的user manual, end users 就要能很愉快的上手.
除了 UI的設計以外, 其實 UI的程式設計技巧是最高深的, 不想寫的時候可以直接給他寫個十幾個if else, 以後 maintain就會累死, 仔細設計過UI程式就可以寫成structure..class, 有沒有努力的 code其實一看就知道, 一點都騙不了人 ...而這一切都是純軟體手工打造, 所有的algorithm都要從腦汁榨出來, 光解自己產生的bug就解不完了, 大部分的時間都是一邊開發新function, 一邊debug自己的程式, 所以一點邏輯功夫真的是必要的...
那幾年, 我就一直以這個目標前進, 到這裡, 可能可以聞到一些味道了, 職場的前幾年真的是在拼圖, 遇到火就倒水, 遇到水就點火, 比較吊詭的是當時我完全不知道我在拼一張圖,
一直在多年以後, 我才慢慢看清楚這個我以為很熟悉, 其實很生疏的ㄧ個硬體相關的軟體工作.
下接不太可能有的 [卷二].
當時架構在smartphone上面的是third party一家廠商insignia, insignia很積極想推VM到smartphone上面, 還好讀書時, 寫過幾行JAVA, J2ME還算好懂, 所以寫了幾個測試KVM效能的小APP, 無意中寫到關於中文字時, 發現KVM對中文的支援很差, 跟insignia FAE討論後, FAE就逃之夭夭了, 不過比較振奮的是, JAVA當時候的三塊大餅, 我吃了兩塊分別是J2SE和J2ME, J2EE就沒有這樣的好運氣, 一直沒有機會摸摸.
在那個時間點, 其實我是認為KVM是大有可為的, 因為它可以在任何的手機平台上執行run anywhere的應用程式,如果那時候 KVM有起來, 現在應該就不會有Android 和iOS之爭了, 回頭再看KVM, JAVA的理念其實對於這個世界的科技是正面的, 只是沒有"能人"知道如何包裝和推動這些技術到使用者手上, 這些工作更是難以讓專門生產硬體的公司來落實. 不過話又說回來, 老賈也是從這幾年的失敗經驗中才讓iPhone一炮而紅.
那段期間, 老實說並沒有很大的案子壓力, 手上有兩隻老大丟給我的最新Nokia和SE手機, 還有一支MS Samrtphone, 每天都沉溺在測試這三隻手機上,每天都等天亮, 急著衝去上班, 其間下載了無數APP和spec, 看了好多手機評比, 甚至還review某家印度軟體公司的app, 只能說這份工作真的是做興趣的, 但是通常有給薪的爽日子都不會太久...
沒多久, 終於有機會看到Windows Mobile(WM)的source, 當時候我對WM的source只能說"非常困惑"來形容, 無窮無盡很虛的API, 還有其實最關鍵是了不了解OS, 我又回去翻了恐龍書, 常常為了看懂一段code, 花了一個小時, 結果還是不解, 但是就是那個時候養成看Windows SDK的習慣, 雖然那段期間甚麼鳥蛋都沒有產出, 但是對我日後寫driver或是app其實影響很大. 也因為這個時候, 發現Windows不是想像中的可惡, 對programmer而言, Windows提供的很多有用的文件, 甚至對我來說印證了恐龍書上的大部分concept.
WM其實還有一塊boot loader, 我當時候的組語功力mov 還會寫成move, 為了瞭解那些完全不懂的code, 全部印了出來, 還好不是太長, 如果是 BIOS還真印不完, 第一次看到boot loader, 終於體會到這真是個令人沮喪的灰色人生, 我幾乎是逐行翻譯每一行code, 過幾年才發現那時候看得那麼苦, 就是沒有拿spec好好對照, 甚至應該還有boot loader的procedure, 蠻幹是行不通的, 資源到手, 才會一路順暢. 還有一點, 當你天資沒有人家聰潁時, 蠻幹硬上更是行不通.
那時候有機會見識到在這個軟體領域有所成的RD前輩, 每一個人幾乎都有所長, 而且把持著自己的成功軟體, 在內部技術會議上侃侃而談, 原來RD和軟體比我想像中還要重要也是那時候在我心中萌芽的.
我曾經看過很多工程師很想做 BIOS, 甚至我還認識非BIOS不做的兄弟, 當然堅持是人和其他動物不一樣的地方, 但是我問他為何要做BIOS, 他只回答我門檻高, 當你token 0改1, 解掉一個bug, 請問門檻在哪裡? 不過那時候, 不知不覺也開始我BIOS的人生, 也許真的門檻高, 讓我這幾年一直為BIOS效力, 不過細說從頭, 有一個不是很順利的開始.
做第一個BIOS案子時, 我對看offset和register薄弱到一個幼幼班程度, 當時候也很認真的從reset vector開始trace, AMI的code據說是call routine比較少的, 當時候我還是吃足苦頭, 常常一個routine, trace到最後迷路.
還有..當時還對Windows的東西無法忘懷, 組語從來沒認真練過, 幸好有人扛起那個案子也不致於太累, 但是"成就感"低到一個地步, 很好笑的是以肉腳來說竟然要用"成就感"來衡量自己的工作, 所以十年前就有草莓族了, 不是現在才有..那時候, 只能說對做 BIOS完全沒有 FU, 做事情還是需要FU這檔事情的.
有一天發現同事在改SM BUS的driver, 無意中我喵了兩三下, 果然有一見如故的感覺, 同樣是寫register, FU怎麼會這麼好, 這不就是我一心想做的事情嗎? 當場share過來做..
其實這支SM BUS的底層程式真正開啟我的眼界, 因為作業系統從98後都有保護模式, 不能直接寫IC register, 很多和h/w有關的事情根本不能做, 軟體無法發揮應有功能. 之後的好幾個月, 我又開始沉溺在如何在作業系統底下讀寫register. 這支程式當時我幾乎是每天看, 回到家還是看, 幾乎背下整支程式.
沒多久我才知道這個程式只是DLL, 他是被另一個 APP呼叫, 這兩個程式合體, 才有化學變化, 沒多久這個 APP終於入手, 其實在這之前我都是用MS提供的Visual Studio IDE, VS K了一段時間為了跟上一個公司的老案子, 又為了MFC K了侯捷的書好一段時間, 但是我拿到的這個APP竟然是Borland C++ Builder(BCB)寫的, 找了一本BCB的書K了幾頁就開始上手, 這個程式裡, 我最喜歡的就是"程式幾乎是從頭開始打造", 那種萬丈高樓平地起的擁有感很踏實, 如果有其他copy來的就是有一段"多邊型UI"的code, 這段code也是我唯一我看不懂的部分, 原來這一段是windows native API, 找來 MSDN努力的 search.
後來我們BCB的環境update, 我順手把多邊型UI改寫成 DLL, 讓他適用在各種不同版本的IDE, 之後產品的多邊型 UI都是用這支DLL. 在那個時間點, 我一直認為硬體底層的讀寫是最困難的, 後來才了解真正的學問在 UI, 硬體的底層只要有 template, 有固定的機制讀寫 register, 但是真的令人傷透腦筋的是UI, 研究所時所修的Human Factor完全壓垮在象牙塔中, 有點像拿Lamborghini V12硬要裝在Toyota上面的那種無奈, 哪來有時間去field research我icon要放哪裡? 用bar好還是用item好?
UI的感受其實見仁見智, 但是之前在手持裝置上的使用經驗, 搞得我越來越龜毛, 手持的 UI和當時的桌面軟體比其實精緻很多, PC上軟體UI樣式一直被MS控制, MS的UI的想法應該只有一點, 就是教育end user, 讓大家接受我們的 UI, 然後擺脫不了他, 但是真正的 UI其實應該不需要任何的user manual, end users 就要能很愉快的上手.
除了 UI的設計以外, 其實 UI的程式設計技巧是最高深的, 不想寫的時候可以直接給他寫個十幾個if else, 以後 maintain就會累死, 仔細設計過UI程式就可以寫成structure..class, 有沒有努力的 code其實一看就知道, 一點都騙不了人 ...而這一切都是純軟體手工打造, 所有的algorithm都要從腦汁榨出來, 光解自己產生的bug就解不完了, 大部分的時間都是一邊開發新function, 一邊debug自己的程式, 所以一點邏輯功夫真的是必要的...
那幾年, 我就一直以這個目標前進, 到這裡, 可能可以聞到一些味道了, 職場的前幾年真的是在拼圖, 遇到火就倒水, 遇到水就點火, 比較吊詭的是當時我完全不知道我在拼一張圖,
一直在多年以後, 我才慢慢看清楚這個我以為很熟悉, 其實很生疏的ㄧ個硬體相關的軟體工作.
下接不太可能有的 [卷二].