標籤

2014年12月10日 星期三

[emotion] 你該做的遠比想像中的多

最近公司有場請原廠來做的內部訓練課程,負責人早在上週就發信出來做準備,這是個好習慣。

因為這場內訓是需要動手玩玩的,所以前置作業由原廠寄出文件來,請大家先做準備。巷子裡的行家都知道統一大家的動手玩環境是最方便的,只要有一個人花時間準備,其他人只要clone他做好的VM image即可。

到目前為止,我很認同負責人的做法。

但一切都變了調,這是我課後感想。

首先,有VM image很方便沒錯,但有沒有跟target device接起來測這是重點,而且每台target device不盡相同,使用狀況也不同,所以像是我們分配到的device跟我NB中的VM就是死對頭,常常出包逼得我一直在restart VM。

除了這點外,環境架設也是問題,事先應該可以調查講師們環境架設有無需要注意的事項,比方說需要monitor來秀畫面,那需要的是D-SUB, DVI或HDMI。有沒有需要網路環境,是區網或是要上外網,所以一早講師們很驚訝這些事情沒設定好,也花了不少時間在做設定,白白浪費了大家的寶貴時間。

很多事實是需要經驗,有run過才會知道整個流程是怎樣走,才能列出check list出來。這跟出國打包行李一樣,很多人都有自己的check list一條一條檢查確認無誤。如果沒有經驗,就會以為只要把VM image準備好即可,但事實上的前置準備卻多到超乎預期。

之前有個經驗是到外部單位訓練,所以是在像是電腦教室的地方一樣,每台電腦都是被設定好可以馬上使用的,講師只要把預準備的檔案copy進去,大家都可以照著做,不需要擔心有東西尚未被設定完成,這是值得借鏡。

還是要再說一次,把事情做完很簡單,把事情做好真的很難。

2014年11月14日 星期五

[emotion] 年輕人講師教我的一堂課

Team裡因為有些工作是比較routine的,所以我們設定找的屬於助理工程師等級的,第一次找人時很順利的找到適當人選。所以沒有任何相關工作經驗,但進公司後我花了很多時間在訓練他,因為期待他儘早上線幫大家offload掉些工作,發揮開這缺的最大功效。

幾年過了,敞產品線的軟體愈來愈強大,開開關關的選項也多了不少,交互排列組合下的組數更是多到我連想都不想。
(更別提,有的選項開了不work,或更糟的是關了它卻整個compile fail)

在順利讓同仁上線服務後,因為其他工作開始忙碌且該同仁上手後,我就很少去主動關心狀況,因為同仁表現可以讓我放心。即便一開始有些compile fail無法解決,幾次之後也成長到自己獨立作業,不再需要我的協助。

因為同仁優異的表現,我們開始調整工作內容,做點工具的開發工作。去年開始因應新產品的開發,這工具類的開發工作變得很吃重,也因為其重要性必須以最高priority來進行,造成這routine工作我們出現人力缺口,也開始了這堂 -"年輕人教我的一堂課"。

課堂講師的背景恰好也是剛退伍,沒有工作經驗,由於職缺需求和條件不需要找頂尖學校畢業的工程師,我們因為先前的美好經驗(?)而開始了這次很難修的課。

Onboard一個月,這期間陸續出現問題多到超乎我的想像,深入瞭𧣈發現問題真的很大,而且在很根本的地方就出包,造成疊在根本上的所有東西都跟著歪。

我花了幾次由正面,由側面跟講師瞭解後發現溝通有問題,但溝通只是工具,被用來溝通的know how更是有問題,原來是基礎不夠。

是真的基礎不夠,或者說根本沒有基礎。
有Server管理證照或經驗,但卻不懂touch之類指令的用途。

正當我傷腦筋如何來避免這堂課我被當掉,週五早上一封通知信告訴我:你被當了!
(當然以後也不用來上課了)

收到通知信後,心裡感受真的很有趣,鬆一口氣的是不用想破腦筋找方法,倒吸一口氣的是見識到年輕人講師的不堪一擊。(之前人家說年輕人不耐操,想找舒適的地方待,我不相信,現在我信了)

死當,這條路的確是這門課原先在我心中最好的選擇,原因是長久走下去的話改修別的老師的課才是傷害最小的路。

只是沒想到,事情這麼快發生,我也只能安慰自己,長痛不如短痛!





2014年2月22日 星期六

[emotion] 接力賽

記得在小學時每年學校的運動會中一定會有一個競技項目是 - 大隊接力。
這是一個由12個選手組成的1200公尺接力賽,每位選手跑100公尺的距離,對小學生短跑衝刺是可接受的設計。

那時,老師很在意一件事情就是「接棒」。
接力賽人每個選手的跑速當然很重要,但還有一個細節的地方很容易被忽略那就是接棒,所以那時我們常常不斷的練習接棒這個看似簡單的動作,而且要做到是直覺反應一樣的自然,這也代表著那些動作變成習慣的一部份,也深剩在我們小小選手的腦中。

如果在接棒時掉棒,或者是下一棒助跑的速度不對那上一棒很可能在己經沒力的時候仍要苦苦追趕做交棒,這短短的幾秒(可能不到2秒)內必須做出最正確的判斷才有可能完美的完成交棒的動作。

每位選手基本上要完成的動作如果拆解的話,那就是助跑-接棒-快跑-交棒-退出跑道,其中跟「棒」有關的就要技巧在,其餘的都是本身能力的展現。

講到了那麼多,回到我想要談的主題,也就是新產品上的助跑。我們部門的新產品在農曆過年期間回到公司,早在過年前長官們開始安排如何準備,包含過年期間的加班,為的目標只有一個讓產品成功到Demo階段,以及可以MP階段。

但有做過產品的人都知道,這整個過程不是一場短跑,而是長跑,需要很多人才和時間堆積才有的成果,但這次我們想要以n倍速來進行,所以每一個棒次間的助跑與緊接著來的交棒就變得很重要,只要一出現差錯,那呈現出來的就是時間延遲。

從過年期間到今天幾乎都有同仁在公司加班趕進度,這其實不是好現象;但實際上這是令人感動的,因為這是團結的表徵。

一個團隊除了其專業能力外,向不向心也是很重要的,因為這代表著大家對於目標是一致的,想要貢獻其專長的自發性是很強的,這種風氣是我很欣賞的。

我自己在這次的瘋狂加班趕進度很開心的也參與其中,雖然很累很疲倦,但是內心獲得的卻很多。每天有可能是微笑下班,或者苦著臉下班,但不管什麼都是有收穫的。

這次的短跑接力賽,大方向來說是smooth的,但小地方仍有許多地方是可以改進的,也希望這次的接力賽可以如期完成。

工作除了金錢,權力外,團隊裡的成員所營造出來的氣氛很多是可遇而不可求的,對吧?




2014年1月9日 星期四

[emotion] Develop V.S. Copy&Paste 哪一種?

最近花了點時間在寫Android App,早在去年初時瞭解到未來工作上需要寫App,我就開始計劃如何學習。

以往的學習方式,或者說是自己習慣的方式,是拿著一本"寫給初學者"的入門書,先窺探一下這個技術的概觀,先不求一次就深入到底,免得自己受到挫敗而心生討厭它。

以上的自學是自己體驗出來的,想起剛開始學寫程式時我在書店很貪心的挑了好幾本書,其中很多都是網友們推薦的聖經,必讀不可,可惜的是這些聖經多半是國內大學的教科書。

教科書?大家懂我提這個名詞的意思嗎?

就是很大本,非常厚,很不好讀,當然更不是常人的我一看就會懂的。

當然啦,那些書後來都被我放在書架上了。(但它們不是被冰存了,在之後的工作中有時也會拿起來翻找資料的。)

書-我喜歡歸成2種。

1. 入門書。
2. 參考書。

第1種的入門書是我會仔細的閱讀,且儘可能的動手做,因為它是我瞭解這技術的第一步,而不用電子書的原因在於我依然習慣閱讀實體書籍,有時也可寫上心得備忘。

第2種的是輔助教材,有時線上文件做得不好時,只好回頭翻查這類又厚又細的參考書,多半可以找到幫助的,加上己有入門書的基礎,讀起參考書自然不會是問題。


似乎離題了,再回到我想寫的。

工作後的學習時間其實是被壓縮的,很多task交辦下來不太允許我再以習慣的學習曲線來學習,取而代之的是更短的學習方式,常常就是:

「學了一點基礎後就開始做事了!」

這時自己就像是一個只會用mouse來做Copy&Paste的工人,因為只需要用google找到參考程式,快速消化一下這種是不是我要的,再善用mouse的右鍵把內容都抓下來,接著就是修改成我要的功能。

這樣做我可以達到最終目的,把功能做完。但卻失去了學習新東西的熱忱,自然也不會在腦海中留下深刻的印象。

學東西是為了交差會變很無力,因為在任務結束後我可能又把這段時間內學習的又還回去網路,這不是我想要的學習方式。

但礙於工作,只能屈於,但另一個新念頭就是放入todo list中,自己再利用空閒時間把該學的補回來,也加深腦中的印象。

我時常在反省:身為一個軟體工程師,該有的技術和態度是什麼?

是Develop還是Copy&Paste呢?

對自己而言,是Develop。 (其實根本就不該有後者那個笨答案的!)而這種Develop是學會了技術,再依需求動工規劃架構,最後才是動手實做。套句這半年我常聽到的話:有尊嚴的!

昨天在公司東湊西湊的把一個功能給完成,但過程中充滿著空虛感,所以寫了這篇文章來警剔自己勿變成那種工人。

我要讓每個工作時間內容都轉化成有實質的產出,而不是只是交差了事。不讓自己的成長只是一直在重覆一樣的內容,如此只是變成更有經驗的工人,卻不是會的更多的工程師。