[Memo] 數位游牧的生活 Part End

Image Credit

13lkg0agi0.jpg

時間過的真快,這兩年的游牧生活在最近算是告了一個段落。兩年的時間說長不長說短不短,中間也發生了各式各樣的事情,所以想把這兩年做一個總結記錄下來。

喜好、堅持、技術偏執

我覺得有時候技術人通常都會有這個問題,不論哪方面的技術、哪個領域的專家,通常都有自己擅長的工具,輕微可以稱為喜好,嚴重點可以稱為堅持或是技術偏執。如果今天是個一人團隊,你想要用什麼就用什麼沒人可以管你,不過如果是在一個團隊裡面,勢必需要做出一定的妥協。

對於 startup 來說最有限的就是資源,有時候團隊空耗了很多時間在這些不重要的事情上面(從團隊能否存活下去,或是對使用者來說有沒有感的角度來看的話),最慘的莫過於都已經達成團隊共識了,最後還被推翻打掉重練…這真的不只是浪費資源,還嚴重的打擊了成員的士氣呀!

技術選擇

這是前一點的延伸。很多時候公司們的技術決策者會因為自己的喜好或是堅持而選擇了特定的工具或是技術,這可以理解,但是我覺得一個技術團隊還是需要擁抱開源軟體,要不然這對於日後的開發或是維護甚至是人才招募會有很關鍵性的影響。

為什麼這樣說呢?以我們為例,我們真的太專注在造輪子這件事情上面了。造輪子不是不好,在某個程度上他讓你對於使用的技術上有更多的掌控與理解,而且可以做許多更客制化的擴充。但是比起 startup,這件事情應該發生在有足夠資源的大公司會比較好,因為通常要維護這種輪子(特別是基礎建設的輪子)會花費大量心力,有時候為了業務需求還要做許多改變,所以如果你們是 startup ,光是專注在開發產品的資源都不夠了,更何況是這些對用戶無感的輪子呢?

第二個問題是社群的力量,就是因為沒有足夠的資源來做這些事情,所以如果選擇了知名的開源軟體當做基礎建設的輪子,那就可以搭著社群的力量前進,更專注在自己的產品上。

第三個問題就是招募還有職涯發展,一來是這類型的私有輪子會造成成員投注了太多時間在其之上,而沒有去研究或是了解市面上比較流行或是大家比較常用的技術(不是要一昧跟風,但是至少要花點時間了解大家在幹嘛),造成了未來職涯發展上的受限。而這個的另一面就是招募也會是一大問題,如果需要找新血來參與開發,基本上他們所擁有的能力是無法在第一時間帶來幫助的,通常還是需要經過一個不短的學習期才能實際上場,真的很傷。

所以如果可以的話,在捲起袖子開手寫第一行程式碼之前,想想這個問題,找找看網路上有沒有什麼現成的解決方案,真的可以幫團隊走得更遠,要不然中途才做改變帶來的成本真的很高很高很高!(真的很重要,所以要說三次)

權力下放

我想各個團隊的 CEO/CTO/C?O 應該都不是一開始就是做這些事情出身的,通常一開始都是專精於設計、資訊…等各個領域的專家,但是是因為公司編制的關係才掛上了這樣的頭衘。

如果初期團隊小,就只有這幾位創始人,那當然沒什麼太大問題,反正每個人還是繼續專精在自己的領域上。但是如果人數開始成長,開始招募了非核心團隊的成員之後,問題就開始了。

有時候上位者並沒有意識到自己職位的改變,沒有辦法適度的把權力下放給同樣領域的成員做決定(像是 CTO 授權給架構師、CDO 授權給設計師…等),而還是把決定權保護的好好的,就會造成上面的人因為要參與的事情太多所以忙得要死,而下面的人因為沒有辦法決定事情所以會浪費很多溝通的成本在說服能做決定的人,甚至是要花很多時間持續改動 spec 直到同意為止。大公司就算了,但是對 startup 來說真的是一大傷,通常這樣一來一往也過了好幾天了。

所以如果可以,請適度的鼓勵下面的人自我嘗試並授權給他們!

持續主動揭露訊息

對於一起在 startup 工作的大家來說,與其說是同事,不如說是戰友還比較貼切一點。比起穩定的大公司,要選擇在種不穩定的環境工作真的是需要拿出勇氣的,更不用說是那些有揹負家庭責任的人。

在海軍當兵的時候常聽到「同舟共濟」這個詞,我覺得也蠻適合用在 startup 這樣的環境。

不管是好的或是壞的消息,為了要讓大家不要有各種過度的想像或是猜測,最好的做法還是持續並主動地揭露訊息。真心覺得這對於實行遠端工作的團隊來說特別重要!

語言落差

我覺得這是在參與過由台灣人及非台灣人組成的團隊之後得到的感觸。以前在大公司上班的時候,同團隊成員之間一定會有著比較深厚的友誼,一定都會自己私約各種吃喝玩樂的活動,然後比較不熟的同事們就比較不會有什麼特別交集,也更不用說是和管理階層之間的互動了。

想想,光是講中文的我們之間都有著這樣子的落差了,更何況是和那些不是講中文的同事們呢?所以如果團隊是由講不同母語的人們所組成,最後通常就會變成兩個獨立團體,吃飯或是聊天都是各聊各的,大吐不快!!

所以如果今天你是老闆而你真的想要了解團隊成員之間最真實的內心話,或是想要和他們有最真實的互動,能夠了解他們所使用的語言真的是一大加分。

任務分配

身為一位工程師,解 bug 對我來說是比較乏味的一件事情。不過不可避免的是程式難免都會有 bug,所以這一定是日常工作的一部分,但是如果持續解 Bug 超過一兩個月而無法開發其他有趣的功能,那真的是會是讓人心情低落!

startup 的 CEO 有時候為了資金的問題而忙得焦頭爛耳,如果團隊裡又沒有相對應的管理階層可以決定未來產品方向,很容易就會陷入這樣的困境,因為沒有方向的話就代表暫時沒有新的功能可以開發,但是又不能讓整個團隊空轉,所以唯一的解法就是要求大家修 bug 或是改善效能,如此而已。

現在往回看,這件事情在當時真的實實在在的影響了團隊的士氣呢。

最後

很快的兩年就這樣過去了,2017/08/01 是在一個團隊兩年的里程碑,我們有歡笑、有爭吵,但是不管怎麼樣還是很高興認識了這群有趣的人,未來的路還很遠,還有各種無限可能。老樣子,想說的話太多,還是找個時間大家約出來喝喝酒聊天比較實在!

謝謝你們 🙂

(+Mehgan, Ratih, Vlad, Pomin, Lucien … etc)

vectr-2

數位游牧的生活(未?)完

[iOS] Compilation time goes crazy when using `+` in Swift

Image Credit

slow-656x330

Recently I have been working on one of my side project in Swift. Originally, everything looked fine, but not sure starting from when, the whole compilation process started to be slowed down a lot from 20s to more than 5 mins!!

Originally I was thinking it’s mainly caused by some of my 3rd-party libraries because I did install some new ones during that period. So as an engineer, I started to bisect and see what’s going on. But after uninstalling / reinstalling those libraries, things are not going well though.

Ok so it looks like this way is not working and not the root cause, so what’s next ? After thinking a while, I started to check codes line by line and see what’s the most suspicious part that can cause the problem.  TBH, there was no any piece of codes looking suspicious to me… Ok no ways to go again, the only thing I could do is to narrow down variables and started to comment out methods from entry point.

After a while, boooooom, I finally found the part which would cause the problem !!!!

螢幕快照 2017-08-03 下午2.31.27.png

What the hell, it’s all about + !! Because I mainly work things in JavaScript, it’s really not intuitive to me that this can be the problem! After googling around, here comes some comments about this problem :

Reference

 

It has to do with type inference. Each time you use the + operator, Swift has to search through all of the possible overloads for + and infer which version of + you are using. I counted just under 30 overloads for the + operator. That’s a lot of possibilities, and when you chain 4 or 5 +operations together and ask the compiler to infer all of the arguments, you are asking a lot more than it might appear at first glance.

That inference can get complicated – for example, if you add a UInt8 and an Int using +, the output will be an Int, but there’s some work that goes into evaluating the rules for mixing types with operators.

And when you are using literals, like the String literals in your example, the compiler doing the work of converting the String literal to a String, and then doing the work of infering the argument and return types for the + operator, etc.

If an expression is sufficiently complex – i.e., it requires the compiler to make too many inferences about the arguments and the operators – it quits and tells you that it quit.

I think I am too familiar with languages like JavaScript, so all the details like this are all hidden and not exposed to us. No matter how, it’s still surprising though. Hope in Swift 4, this kind of basic operations like Array concat can be optimized and boosted up.