離開 Front-end developer 新手村
終於，第一份工作可以結束了，很久沒有心情上的滿足了。
連同過去兩篇文章，給這段時間一個交代。
關於這第一份正職工作，分別以「前期」「中期」「後期（此篇）」寫了三個時間點的文章，有些期間寫的時候比較情緒化，也在這篇後期總結一些之前文章不客觀的地方。
入行 2018.06–2019.09
重新介紹一下，這份工作是上一個服務業做4個月覺得沒機會當店長（大家都有自己開店的夢想 Ｘ）
離職後回來看前端然後一個月隨便投的。
當時只有投兩間台北（開40k-45K *13）三間高雄(30k-35K *12)，回顧我當時 JavaScript 等於不會，只會 HTML,css 且不熟練，我覺得這個區間差不多（基準參考7–11打工）。
本來想三個月後調薪喊 35K 否則離職（當時熟練 web-layout, jQ 的感覺也抓回來，還導入了一些改善整體部門效能的工具），雖然後來直接給33K (年終0.5 三節都是禮物約200–300)，但我也懶得離職重新找就這樣定了，一直到離職共做了 1.25年 都沒調薪。
自己觀察及持續面試試水溫覺得（每隔三個月左右就投看看），如果可以純粹靠自己兜出一個功能健全的 Demo (不是看線上課程 step by step / 拿課程當 demo，那些都是有code的，很難讓看的人認同是你的實力)，如果沒有準備 Demo 的 方向，今年 F2E 設計作品大量噴發，可以參考。
總結來說，有使用框架且有熟練度，也有工作經驗，台北 45K-50K * 13/14 應該不是難事，但高雄大概就 35K-42K *12 吧。
對了，忘了聊聊我離職前的工作，我的工作業務主要是幫公司內，其他部門開發方便使用的線上平台。公司想做雲端服務的概念，我隸屬部門約 30人 ，前端人數不包含組長 5 -> 3 -> 2(我離職後)。
其他部門（約50–70人）會使用我們開發出來的服務，有點像 beta 使用者 ＆＆ 核心用戶的概念。
然後公司氣氛很符合「從眾效應」，因為大家都不會說話不會表達意見，部門開會 30人都不會有人「有問題」 （除了我和少數幾人，但要解掉從眾效應確實活躍人數不夠，事實上一直有提出問題也不會怎麼樣，不過這個部份要靠自己觀察公司風氣，有些公司可能真的會出事…吧？），這應該很符合台灣多數公司的狀況，大家都來打卡領薪水就好，公司裡面大概只有3–5人是真正對開發有熱情的，但有熱情的人通常很快離職。
這類服務（老闆期望的）最終目標都是要面向市場，不是躲在公司裡面自high，但我入職以前到離職前觀察，就連公司同仁當內部使用者的活躍人數都不足20。
雖然也是因為如此，工作以來沒有加班的需求，下班準時閃人。
「前期」：Front-end rewind : 半年才準備跨入 junior
這篇文章的時間點大概是對基礎刻板都非常熟悉，然後對 jQ 有一些瞭解，不過工作上還是「刻意」使用原生 Web API 且引以為傲，很幼稚的屁孩想法。
也有在文章裡面提些工作相關使用技術，總體而言是大概快10年前的後端為主， tech stack（PHP Smarty），公司不排斥用新技術，所以我自己離職前玩的都還算是主流前後端分離（angular+laravel)，沒有碰到太多legacy code。
總結來看，實務上是如果有大量開發使用 jQ，還是以 jQ 考量就好，因為很多時候對junior來說，「可讀性 」遠大於效能，尤其是你不能證明你優化的效能是在 Critical path，不要故意使用原生語法（但要了解 jQ 也能用原生做到的方法）。
對於設計與工程協作有一些想法，一開始還沒有機會可以實作，後來嘗試從很多方向下手也有慢慢取得成效。
這段時間也意識到自己寫文總體而言質量不夠，如果要靠數量取勝可能不如當自己寫日記就好，不必特地放在 medium。
這段時間也特別自傲（貶意），因為過去的實習經驗與自己的學習能力在工作職場上進步的非常明顯，明顯到讓自己過於驕傲。也不太喜歡公司內小圈圈討論八卦的氣氛，所以後來選擇不與公司同事有太多非公事的交流。
雖然結論證明不要太過深入辦公室政治的選擇是對的，不過之後可以考慮不要那麼果斷拒絕。
當然，我知道這段時間的認知是不是自大，是得益於透過很多社群、活動的會後討論、和社群大大交流得到的回饋，也是這段期間認識到「參與社群的重要性」。
也因為如此，才把自己態度修正回來。
「中期」：參與社群，GDG Kaohsiung ，Rewind Myself
這篇文章主要是透過參與社群來瞭解自己的定位，順便修正一些自己還過於幼稚、偏激的想法，畢竟小時候（大學）以為當「工程師」是「希望不要和太多人互動，可以自己一個人面對電腦」，長大才發現要成為出色的工程師，要像公關一樣「擅長與人溝通（最好能通靈）發揮影響力、有耐心解釋問題/diff review 、邏輯清楚可以敘述事件」。
這個階段比較多想的是下一份工作的目標了，因為當時在扛新專案起始的前端架構，說真的沒有使用者的自 High 服務很難驗證自己的架構方法，基本上公司也沒人可以指點我，我的決定方案通常就是最後方案。
不過前面有提到，公司沒有什麼使用者，所以多數時間拿來做研究、拿公司的產品當做打磨練習的對象。
期間和有當過台灣某數字人力系統的技術 Lead 請教過，這之後才真正開始理解「公司文化」的意義，也思考自己未來的 career path。
後期 ： 省思，到離職前我做了什麼？
Angular 作為一套完整框架，學習過一遍基本上能疏理好前端觀念，唯獨靜下心來好好看 code ，這好像是蠻多 junior 做不到的（觀察同事，自己，感覺是過於躁進？）。
因為整套都是 google 所以不用擔心離 best practice 會差太多，透過研究 material 的元件開發，看到漂亮分離 css 的 css 模組化寫法，看到大量表單內，class style 繼承的用法，也用 Rx.js 享受處理 pure function 的乾淨俐落。
不過缺點是，畢竟和 React/Vue 主流前端的思想差異較大，一些流程的開發邏輯也不太一樣(比如關注點分離的角度 )，尤其 16.8 之後 functional component 真正發揮作用，生態系可能會減少 class style component的依賴。
如果以出國工作為目標， angular 的工作機會又太少（對比 React ）。
離職前是 Angular + material 魔改為基礎，目的是自己想嘗試元件化共用樣式的開發，但沒經驗所以大量參考 material ，最後就直接魔改成公司適用套件了。
雖然是一套簡單的架構，但優點是大量資料可以參考，多半也都是官方維護的文件，儘量把初始的架構在保留擴充的前提下做到簡單。
選用 material 也需要大量溝通，很多時候一些「理所當然」的事還是要找文獻證明，也符合中期文章提的「有機會影響設計和 UX、累計開發前後端合作開發經驗」，困難的不是在開發上，仍然是在溝通上。
舉個例子： 搜尋條件 default 應該是沒有條件，但上面總是覺得要保留狀態，然後又不原因在畫面上保留 filter field，所以找很多資料來證明。
為什麼想離職？
本來文章差不多完成，然後看到 js 群組裡面有大大說公司有招聘。
在 Linkedin 看到是 Grindr 的 VP，也在 Linkedin 當做一般人，比較隨意的留言，後來看到 Alexander Lin 半路出家軟體工程師在矽谷的直播影片，驚覺自己留言到大神的地盤，順便看直播重新反省自己。
也透過直播影片，重新整理自己要做的事，重新理解「頂尖工程師」的思維。
所以後面文章雖然是直播心得，但基本上都是讓我思考離職後下一份工作的內涵與選擇公司的方法。
直播影片主旨：討論提供高薪的公司，他們要找的是什麼人？
這邊不討論純開源的開發者，比如 linux , vue.js 之類的開源開發者，他們都是很厲害的頂尖工程師，不過這邊單以領公司薪水的 developer 為 scope。
什麼是 「一流的人材」？
工程師人群很多，但總是缺頂尖人才，這邊聊到頂尖人才會有幾個特質
（擷取FB整理，後續文章也部份擷取，不再贅述）
一流的人材是能幫公司把一個 app 從 80 分做到 100 分，矽谷科技公司願意花大錢雇用這樣的人才。
因為一個成熟的 App 會遇到以下比較有挑戰性的問題:
1. 維持 code base / code quality： 它內部的邏輯，模塊之間的交互是非常複雜
頂尖的行動開發工程師可以在 code review 中把關(不要merge有可能有問題的 code, 才能沒有 Technical Debt)，在架構上調整， 讓 app 可以持續進步。
2. 效能問題：運行效能開始低落 (啟動速度變慢/某些畫面掉FPS)
3. 優化問題：App 變得肥大
4. 如何 migration smooth ：有些老舊的 library 須要汰換升級
5. 如何 migration smooth ：現有的架構讓想加新功能不好加
6. 會有一些 crash 或是 bug 非常難以解決 。
這邊舉例，比如crash rate : 99. 9995，要如何更進步？可能需要以下能力：
- 打點分析 / 插數據 : 分析問題、思路分析、驗證問題假設，由數據佐證自己的假設。
- 某些版本對某些 API 可能有相容問題，拿不到 device 的情況下，要如何找到那些只有 0.001% 的 bug
好的特質 / 行為
- 邏輯思考能力 / 思路清晰
- 抽絲剝繭能力高 (不是設 Breakpoint 可以解的小問題)
- 溝通能力強，知道如何做有效率的溝通
- 知道如何做 diff(code) review 找 邏輯問題/效能問題 ，不是侷限於 naming issue, coding style
- 架構上可以提出建議，分析優缺及原因
- you know Direction : 知道現在最重要的事情是甚麼，把它做好。而不是交代一件事做一件單方向接受。
- 比如說，可以自己思考 code base 有那些問題，是不是要當下處理 (以及為什麼當下處理 ? )
- 如果是有很大 impact，懂得和 stackholder 溝通拿資源(&時間)想法辦做好 / 解決，因為有很大 impact，所以花時間處理後也可以獲得很大效益。
e.g.
1. OOM (out of memory) : top crash percentage 有多少比例要處理? 95%? 99.5?? 99.9995%，處理難易度如何 ?2. 可以找到 critical point 去快速改善效率(&品質) / 降低 crash Rate
上述 特質 / 行為 可以透過 interview / coding test / system desing (large scrop practice) 分析，找最佳解 + 實作，也因為如此現在 code test 的面試才會流行。
不好的特質 / 行為
- 基礎指令 multi-branch / rebase 不熟悉
- 需要 be predictive , 否則容易被 block ，造成沒事可做
- 對於遇到的問題習慣用masking the problem的方式去解決
1.只是找方法補起問題 -> 直接在該處掩蓋問題
2.不找 root cause 從根本解決，用case by case補 bug
- 不知道/不能講清楚 專案 detail(邏輯) , big picture。你無法很有條理的把項目相關的邏輯解釋清楚
- 過於線性處理單一，而不是從 high level 思考問題。
- 看code的時候，只管和自已實作功能有關的部份
什麼樣的人在科技公司容易成功， 升職到更高的職位？
參考 facebook performance review
- Impact : 產出 / boost DAU(Daily Active User) 1% => God / boost revenue 0.01% via Algorithm ＝> king
- Initiative (Direction)
- Influence (Engineering Excellence) : diff review , Constructive review
- Communication (People)
如果沒有人可以 diff review , 去 review open source code
挑選一個能讓自已快速成長的戰場
- 基本原則是公司成長 => 人成長 ，否則就是 career 停滯。
公司能提供的發展空間很重要。對於自已的 career path 在規畫的時候，須要注意自已做事的內容，是不是有持續的提昇自已的價值。 - 有人習慣每年跳 +5K => 容易停滯到某個節點（比如 60k / mo ）
- 有好的business model / 有淺力 / 成長：
公司能有發展，持續賺錢，有正向現金流，個人也才會相對的有機會發展。
5人 -> 50人 沒被淘汰自然會成長
- 看公司的 business model/成長/高層的背景。
career path : tech(expert) or 管理職
管理階層決定價值觀 / 文化Eg 學經歷不好:很容易達到天花板 (對方)
- 直屬 leader :
- 感受邏輯(make sense)好不好？
- 有沒有眼界/眼光？
- 未來要共事、溝通 能不能接受？
- (tech) diff review 能不能抓到邏輯盲點、能不能討論？
- 對方懂不懂你工作內容的價值與難度 (和$$ / 陞遷有關)，不懂容易被輿論（或其他）影響 （了解自已老板的 background，很多人做不開心是因為老板看不懂自己的貢獻）。
不能找常常出奇怪想法：「我覺得應該要做…」的人當主管或老闆
Q & A
支援度問題
- 支援度有多廣取決於 business model -> business Stage
- Start up 先做 先做 premium user => 高階市場 [reference : 特斯拉]
- 先發展高階市場，飽和後，再補中後段市場(emerging market 新興經濟體)
native 開發
- 要做進階優化還是要做原生
- airbnb 放棄 RN => 要做native
- native 有比較新的 API ，可以做比較細節的優化 tuning
自己有 feedback loop
- 不要停在目前狀態，去觀察強的人做的事
- 不要覺得自己沒東西學 => 停滯
- 找如何可以「做更好」
總結規劃
目前應該先回顧基礎資料結構＆演算法，基礎的coding能力足夠才可以去試試，後續會有一系列筆記（洗到抱歉）
然後再嘗試請教看看大大有沒有機會聊看看，果然還是想知道一流的世界 ＱＱ
