人生第一次Coding在大學,然後就一直做到現在,剛好十年。

坦白說,還有很大的進步空間。但卻總是覺得幸運

前途問題

遇上不同的人,對「不理想的現實」感到很多的不滿。工作時間長,自己做出來的東西明明很不錯,卻還面對無理客戶和上司的要求;甚至有朋友直言做Software Engineer是低下階層,總是渴望不用理會Coding而能升上管理位置。

這正是幸運的一點:我總是能找到Coding給我的樂趣,每天都總是有新的想法做法,想嘗試挑戰以往自己的做法,每天有新樂趣便成。(也太簡單了吧?)

現在卻是公司想請一個好的工程師也難的世代哈哈。在供不應求之下算是吃香。也是幸運的一種吧。

有朋友指再過十年,你的競爭力比畢業生低,還從事工程師嗎?我也不懂如何答。我沒有很大的意欲升上管理人員,或者自己一直就是尋找藉口,逃避上位避開責任的問題?

學習問題

出來第一份工作,我發現自己跟老闆Coding的差距,做好Coding其實Hard skills很重要,有感自己永遠都追不上的樣子。有幸就是他,遇上了讓我感興趣的Lean Startup書。或者就是一切的開端。是對書有興趣的開端。之後也一直買了很多書。

到現在則是放眼世界,其實還有一段很長的路學習Hard skills Soft skills。他們同樣重要,但最重要的莫過於學懂學習的方法。

我最怕重覆做著相同的事十年,然後告訴別人:喂我有十年經驗,但實際經驗只得一年。

幸運的是自己有很多機會嘗試,接觸到很多Project吸收經驗,甚至學習一種新技能新體驗,刺激一下創意思維。亦有幸認識到一班做事認真的同事朋友,有些時候還在熱列討論Technical問題,可以談得很起勁。

到現在我還是會讓自己「回到過去」,思考面對同樣的問題,會否有更好的做法。在離開舒適圈與不舒服的中間,找到理想的學習速度就不錯了。

面對長時間工作

雖然很想持續學習,但我也有長時間工作的時間。

第一間長時間工作的公司,同事們都十一點回寫字樓,兩三點回家。我都有OT,但幸運的是:那時上司有牙力,讓很多同Team的同事有空間,所以除了第一個月,之後的工作算是輕鬆。我自制了不用OT的時間,好讓我回家都繼續學習。

我發現有些 OT 其實能夠避免,有些則不能:不論是因為能力不足所以需要更多學習空間,或是一個不可能追趕的時間表。也許是我有正面面對OT的經驗,及後有兩間工作過的而又誇張的OT,我想算是處理得不過不失吧。

但暫時還是有一種很強烈的感覺:要做得好,就要休息足夠。

我樂見之前參與的某個Revamp中,有機會一展所長,同時堅持休息時間,有不少好方法,都是第二天早上就忽發奇想。寫的Code真的比以前靚仔實正。離開後也知道維護得很容易,擴展也是,所以很感恩有這機會打好一些根基,現在才有感自己是Senior的樣子。

工程師不是生產機器,生產過程是充滿人性的設計與執行。而好設計,需要休息,腦子才有點子。能夠脫離長時間工作的惡性循環,已經是正向循環。

溝通問題

Soft skills 則是很有趣。

一直也很少說閒話,卻發現要說的話也不是不能,不過做出來還是有點突兀。

我不懂修飾不夠圓滑,給人一種不懂溝通的感覺。有三間合作過的公司,(碰巧都是Senior)對我的溝通能力卻滿有懷疑。但更有趣的是:現在上班的同事問我是否一個「文人」 — — 他認為我與其他工程師有一種不同的感覺,直言覺得我的詞彙我的談吐很不錯。

我想:溝通要圓滑,要讓別人明白你的意見,看來也需要時間磨合和技巧。

最近總是想到一句名言:「你遇到的人都有其困難」。所以在嘗試體諒。

不理想的現實

還有買樓、家庭...其實都不太有問題哈。但環境不理想是無可避免。人總是要尋找在不理想的環境中生活吧。Thanks 子華。

最後

慢慢來比較快。再來多個十年吧。


源起

突如其來的想法,太多idea想實行,卻偏偏懶的運用調劑枯燥生活的週末。為何不試試四天工作?

如何開口

我開口的方式很直接:向公司提出review 安排,順便提出想法。

剛巧接近一年的review,時機尚算合適,順便可以討論薪資安排。我指出我個人的效率,四天工作就做了別人五天工作的事;加上有想學的東西(Machine Learning),所以問公司可否安排四天工作,或許這個安排能給予公司回報也說不定。

(謎之聲:或許只是你不夠膽開口。或許你總是怕你的上司會問你為何提出這些不可能的事。或許同事會問到,為何你會有特權。)

但當時沒有亂想以上的東西,很大膽便是。

實行四天工作

其實和平日工作方式一樣。碰巧公司重要大事都是星期一多,所以需要與別人交流溝通的,都安排在星期一。這小小安排卻更能提高我做事的效率:

一、集中星期二三四全力工作,更有節奏做事

集中力對軟體工程師來說很重要,不用多說。當我與團隊互相安排星期一主力溝通,便有三日可以集中工作。遇上問題,星期二還有時間可以釐清問題。

因為四天做五天的事,工作上很少再思考其他無謂的事。意外的提昇了點集中力哈哈。

節奏的培養也很重要。個人感覺,因為四天的安排好像和我合作的隊友都要有些特定安排,所以每天checkin,星期一主力溝通等都像是上課時間表般安排好。雖然沒有像scrum那樣嚴謹,但某程度上我更容易安排集中時間,不被雜項事情打擾。

二、處理最重要的事

四天做五天工作,自然就將最重要的東西,迫使要放到最前處理。

不只是我一個人而己,團隊也需要了解何為重要的事情,然後交托到我的手裏。

有點20/80的感覺:將最重要的事放在星期一二處理好,不就是提升效率的方式麼?

三、身體健康

少了一天工作,壓力能有三天舒緩是很不同的感受。本身就是愛將工作帶回家的體質,卻因為多了一天緩衝過後,有更好的睡眠質素和時間。過海交通的壓力也少了點。

多了一天時間,所以在家煮煮自己想吃的早餐午餐,很不錯。

另,在星期三在的時候,會感覺到,過多一天就放假了,感覺衝過一週的力量比之前更大。

星期一沒有太多Monday mood, 因為都好好休息了三天了哈哈。

四、完成課程

完成了Coursera Machine Learning course!

後記

多了時間,也就多了亂想的時間。遇上了些 Quarter Life Crisis?反而選擇了離去而不繼續為這公司工作。

人生啊,有時就需要些高低起伏便是。


看了第一集 Monday Morning,內容主要關於一班醫生做術後檢討。第一集共兩次的檢討會中,都是一大班院內醫生,加上一位主持人負責。主持人會選中某一事故,然後叫主診醫生上台,接受主持人一步步的質問。

這一集中,讓我最深刻的,莫過於第二論的檢討會。沒有血肉模糊的鏡頭,卻彷彿讓人窒息。主要是一個小孩位於腦中的惡性腫瘤,因為主診醫生忘記了做兩件事:

  1. 重大手術應該詢問第二意見
  2. 未做好背景調查,了解因為單親家庭而未能即時聯絡上的,病人的父親的病歷史

結果病人就死了。

最後主持人單刀直入,指出主診醫生的傲慢、自負,忘記了這些基本步驟

我想,這種回顧對醫生進步很有幫助,但做法實在讓人抖不過氣,很大壓力。(當然,不能忽略,電影節目為了增加吸引力,而設定這種回顧的方法哈哈。)

最近公司每天的工作也是抖不過氣。

隨著死線接近,越近就越挑戰著半年以來,堅持之下的固定模式:每天Refactoring,不論大小。每次都作一點兒嘗試,去做好每一個功能,不論大小。

很高興在兩次的 Milestone中,都發揮著平日Clean Code的優勢:臨時在Demo前要求加上的新功能,都能夠加,並以一種快靚正的方式,嚇到了不少同事。(本來不需要OT啊不過團隊都加班我不用又好像說不過去…?)

可惜的是,如果沒有同事們的通力合作,隨著編程時間越久,就越覺得阻止不了爛Code的出現。或許事情未變太壞,「針唔拮到肉,都係唔知痛」。我覺得編程與醫生有兩種相同之處:

  1. 基本步驟
  2. 沒有醫生未犯過錯

正常情況下,沒有外科醫生不洗手就動手術的。

正如沒有經過時間去思考如何擴充系統,沒有了解清楚就設計了一個過度設計結構,沒有嘗試了解清楚問題就亂去訂解決辦法,只會為未來帶來很多不必要的問題,在時間和人手緊拙的情況下,就更能放大這些,本身看起來很小的「小」問題。

我想,基本步驟就是需要每一個位置多一份「小心翼翼」。技術上可以引入Unit Testing, Integration Testing, TDD, BDD, 慢慢做小心做;Code Review,每次Sprint收窄範圍,釐清問題與收貨條件,團隊隊員清楚要實作的功能後,即使在死線之前,也不用太著急;問題與方法分開思考,越懂思考別人提出的想法,背後想解決的問題,總會有一些更容易解決的辦法;遏止不斷渴望增加功能的衝動,反思每個功能背後的重要性;越多你不需要做的事,就越能將時間,放在最重要的事情上。

團隊看來太少時間回顧一直發生的問題,又很少投放時間於「重要但不急」上,所以往往到死線前,總是心急如焚吧。

犯錯是不能避免,但降低犯錯後帶來的後果,其實一樣重要。

我想,我也要學會謙卑,忽略了學習的機會。就正如那位,犯了一次錯的醫生一樣。


口中常說:我用緊scala。

但個人感覺,自己學得不到位,scala community 其實有很多工具未好好使用,每天都像是為了完成某些功能,忘記了好好去學習自己不懂的東西。

很難得在多了空閒時間,所以也在慢慢摸索自己對 scala 的認識。

這次是 rabbit mq + akka stream 。

朋友一句:

Unleash the power of Rx. It’s not just a multithreading tool. Treat your data as an infinite stream. You will realize how simple your app could be.

我便總是在想,可不可以將 rabbit queue message 變成一條 infinite stream,然後可以寫成 Rx 的樣子?

稍微 Google 了一下,先是找到了lightbend 分享的例子。當中使用rabbit 的例子不錯,是很簡單的listen一條 queue messages,如果message當中有字 terror,將它放進另一條queue,沒有,便將它放進 okqueue。

發現當中使用了舊有 akka stream experimental 的 signature。稍稍修改後,變成了最新的 Akka stream interface 的樣子

本來高興了一陣子,直到發現了,本來一直有用的 op-rabbit,竟然有 akka stream support? 結果,我嘗試使用oprabbit + acked stream,實作了我心目中的 Rx 寫法

很感動的說,前後嘗試了小小時間,學懂了幾樣東西。

  1. 大神的Code真的很漂亮
  2. 大神的例子鮮明實用,在scala community 不常見
  3. Acked Stream 將 akka stream 補上 Acked 的功效,有點兒像朋友寫的 ErrorT:將XorT 加上 Error Handling 的特質;functional 真的很有趣
  4. Life is too short for sbt,用上了這個 coursier 後,下載 depenency jar 真的快了很多倍
  5. 可以為自己實驗用的東西,都寫了一個 bootstrap 的工具給自己玩。有齊 docker,test工具和 coursier,不用每次都要由頭 setup ,感覺很爽哈哈

第二樣學習的東西是玩玩 Python,完成了Data Science in Python。

這個課程其實有五部曲,而這是他的第一部曲的課程。沒有Statistics基礎的以為會很吃力,但只要最後一份功課的最後一條,才會發現不足哈哈,不過討論區當中不要問題都問得很好,有些提示幫到你完成課程。

課程只有四個星期,每星期其實只有不多於一小時的影片,但有很豐富的Programming Assignment。你不用安裝任何程式,便可在網上寫程式,以便完成功課和自己寫寫Python程式。

Programming Assignment 非常實在,全部都是用上真實數字數據。不少是從 Wikipedia,US gov open data中抽出來的直實數據,問題也很實用,很在地。所有功課都要求你,要自己 Clean Data,抽取數據後,將幾個 Dataframe 合併扭扭。

這課程因為很新,所以你網上找不到任何答案。結果你能很專注自己Google 如何使用 panda, numpy, scipy 的工具,學到的,便是自我解難的能力,和一大堆實用到不得了的python tools。而這些東西,我可以很大膽的說:學完後,你可以很快的幫助到實務上的工作,特別是需要接觸數字,了解公司數據的地方。

推薦大家這個課程。


最近在忙這個基礎得不得了的machine learning class:

大學時代學了一點Data Mining的東西,加上這個 Machine Learning 的線上課程,好像又認識多了點基礎。

一直以來對Statistics不敏感的我,上這個課程還算是輕鬆的。課程上一直都說:「你沒有甚麼甚麼數學基礎無所謂,我告訴你從數學中得出了這一條公式,你可以用。」

所以很有趣的,變成一個Machine Learning的入門課程。先後共需要上十一個星期的課程,每星期大約有一兩小時的影片,半小時的Quiz,和三小時的Programming Assignment。

課程上有兩樣東西都很難:Quiz, Assignment。

Programming Assignment 共有八星期的份,教學上需要安裝免費的 Octave ,就可以任意提交功課,可以試到答對為止。如果本身就對Vector敏感的人,我想Programming Assignment本來就不是那麼難。有時做完功課後,就發現,原來答案是這麼淺白,題目其實有很多提示之類。

不過有趣的是,Assignment中間有些提示,還是教你,如果你不太認識Vector,不要勉強,不要先用 Octave 的 Matrix 功能,不如先用簡單的 looping 想像;想好了便可以使用 Vector 來實現。不過坦白說:直接使用 Vector ,執行起來又快,答案明顯簡單、直接。

最難的,還是小測驗中,每次都只有五條問題,但問得很刁鑽。我很少有的,有一兩星期可以第一次就答中所有問題哈哈。

上完後要 USD$79 可以買 Cert。結果就買了哈哈~

個人感覺:找個朋友一起學,會學得快一點哈哈


Image for post
Image for post
The Accountant — in Hong Kong

過勞死,本是從日文而來,充分表現日本長時間工作的文化。在《如何成功地在亞洲植入敏捷和DevOps》一文中提到:日本人更願意看重的是投入而非產出,因此對長時間工作的人評價很高。

但這不只是日本而矣。我感覺,都籠罩著整個亞太區。不少朋友的公司,總是將多勞多得的正面精神,扭曲成偷懶、不OT是罪的奇怪心態。

但「唯結果論」,準時放工,又能按時完成手頭上的工作,不是更好的選擇嗎?

Learn how to learn 的課程當中,總是提醒著學生,在面對棘手而困難的時候,盲目地花時間去「鑽研」、轉牛角尖,不一定能解決問題,或只是徒添煩惱。相反,我們應該:

給予自己短暫休息的時間,在身心放鬆的狀態之下,更容易該腦袋「發散」思考。最後在之後解難所花的時間裏,有效率地解決問題。

入面甚至提出,每晚睡覺前,可計劃明天的待辦事項。你的潛意識會自動運轉,在休息過後,難題會自然迎刃而解。

在Uncle Bob 的 《Clean Coder》 中,對超時工作有個頗有趣的取捨:

You should not agree to work overtime unless (1) you can personally afford it, (2) it is short term, two weeks or less, and (3) your boss has a fallback plan in case the overtime effort fails.

這段文章總是提醒著我,我們是人,不是機器人。我們有人性,不能長時間工作,同時保持高質素的工作產出。有時整個團隊配合,在短時間內合理地超時工作,並採取彈性上班時間,比起盲目守時開工,保持高士氣之餘,公司會走得更遠。

文中有另一句我頗喜歡:「我發現一旦(日本人)嘗試了 (Be Lazy) 這種做事方法後,他們就會喜歡這個理念。」

「偷懶」一詞,看似貶義,不少人不明白它的價值,或許與自己一貫價值觀和經驗相違背。

唯有實踐過後才會明白。(改變公司文化最有趣,但再說就有一點離題了。)

正面偷懶的方式有很多種,個人感覺:學懂分緩急輕重尤其重要。

Priorization isn’t choosing what to do, it’s choosing what _not_ to do.
https://twitter.com/jeffpatton/status/796667408836661248

在大學學習生涯上,有一位朋友,99.9% 都會找他做組員。他總能在某些「自由發揮」的程式功課中,每當我不斷無限放大功能需求之下,願意一起討論,並提出可行建議,以最小化時間,獲得最多「分數」。

同樣地,差不多每個客戶或上司,都想不斷擴大想要的功能

而在很多功能之中,我們卻鮮有地排序,去決定不需要的功能,造成浪費。有幸在某些好項目中,能成功限制初期項目大小;了解何謂「必要」與「非必要」功能,最後可以在短時間之內完成,從重要的基礎上,慢慢演進去更好的方向。

最近在上另一個線上課程:Machine Learning

我總在提醒自己:好的東西,急不來。

(不過行為上還是很心急。總是要強行提醒自己放鬆心情和設下時限學習,免得影響第二天工作就是。)


Image for post
Image for post
There are two thinking models — focus and diffuse. And these two methods cannot be used at the same time.

同事問了一條有趣既問題:If you can learn one thing instantly, what would that be? (如果你可以「秒懂」一樣東西,那會是甚麼?)

我答:如果我可以學懂一種方法,可以「秒懂」其他東西,那不就是最好的選擇?

最近的確在學習「如何學習」。https://www.coursera.org/learn/learning-how-to-learn/

只是第一個星期已經讓我大開眼界,其中有一個有趣的短片提及一位寫作高手是如何寫作,我卻嘗試將她所指出的問題,放進到Software Engineering 的世界哈哈。

她指的問題是,我們一直學習寫作的方式,特別是在中學時期,都經常教我們:先寫大綱,再寫文章。但她卻發現這一種方式就像是預備吃飯的時候,一邊放碟子上枱,一邊做清理的樣子,最後你就吃不了一餐飯。文章要寫得有趣,需要在寫作前多一點「發散」,而她選擇的方法是 Mindmap 。

最近就發現到自己在寫 Code 的過程中,有時候會出現同樣情況。我會一路擔心這個寫法會唔會行得慢,好像那種做法又有些優點,現在的寫法又有一種缺點,應該要提前做多些 Design 先再開始嗎?

結果就容易導致不斷的修改,同時又想不斷的完成某一功能,但時間卻因為不斷在兩種思緒之間掙扎和跳脫,結果得不償失:時間又過了一圈。

在這個 learn how to learn 的 online course 中,其中我學到的是大腦思維,並不能同時讓「發散」和「集中」並存。我的了解就是一心不能二用

如果在寫 Code 的過程缺乏單一目標,經常在 coding 的過程又要想像 Performance Optimization,又要兼顧 Error Handling,又要 implement 實作功能,只會對你寫 Code 的效率大打拆扣。

我自己的做法會是嘗試用 TDD 的策略。

Red - Green - Refactor!

嘗試在實作的過程前,寫好測試,便容易規範自己的目標就是處理一件小事,不讓自己作出他想,達致高度「集中」;如果見到有問題的地方,簡單加上 TODO 或者放入 github issue 作紀錄;到 refactor 的階段便開始作出「發散」模式,嘗試想像有那些改進的空間,才開始整理你覺得有問題的地方。

即使是不用 TDD 的你,我覺得能夠成功將「集中」和「發散」兩種模式,在同一時間只用一種,便能提昇效率。

放到 Business 思維下,又有一種有趣的想法。不過這想法很大膽哈哈。

在我的觀察中,不少人覺得 Business 是一種可以靠邏輯運作,越 Make Sense 就越好。

我想這種想法,只是偏頗於以常見的方式了解商業邏輯,但事實上是很多商業邏輯都不能單靠正常邏輯思維了解。

意思就是指,如果我們太依賴自己平日接觸的東西,就誤以為那些東西是合理和正常,我們就像是依賴「集中」的思維模式去思考和解決問題。「集中」有其好處:如果兩個問題具有很大相近性,用相同或相似的做法去解決問題,自然就是少了風險,甚至更快的解決問題。

但往往在商業範圍中,我見到的會是完全跳脫日常生活所了解的東西。而這一種商業邏輯,我覺得是著重「發散」的思維模式才能出現。

例如 Zappos 這間大公司,曾有一段時間靠 drop shipment 這做法,佔了公司不少比重的利潤,但也選擇放棄整個 drop shipment 模式,而選擇自己管理倉務和運輸,結果利潤不跌反升。公司可能因為少了一個 drop shipment 增加了價格上昇的壓力,又對買家、客戶增加了相應的負面感,但為何他們會選擇這條路?

又有沒有公司覺得因為不能得失客戶,而選擇維持現狀,只懂「增加」而不選擇「移除」?

這,又是另一個故事了。


最近想試玩 crawler。想開始試的情況下,卻發現公司電腦有安裝 docker,自己的 macbook 竟然無裝!結果急急設定好環境,發現同之前玩 docker 的感覺好多不同之處。

希望設定好之後,不論玩 scrapy 定係 pyspider 都應該無問題。

Step 0: 安裝 Homebrew

我想安裝 Homebrew 應該是每個 macbook user 都會有的 MacOS package manager?

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Step 1: 安裝 virtualbox & docker-compose

brew update
brew install virtualbox
brew install docker-compose

安裝完畢後會送上 docker-machine 的 command line: docker-machine

Step 2: 在 Mac 設定 docker-machine 環境

docker-machine create --driver virtualbox default

行一下就會多了一個 1GB 的 docker 運行了。

Step 3: 讓你的 docker 認識你的 default env

eval $(docker-machine env default)

環境設定完成,之後慢慢繼續。

About

Polar bear Journal

Agile lover. Chinese Calligraphy lover. Brain hacker. https://polarbearjournal.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store