嗨大家，今天是 2016 年的最後一天了，先預祝大家新年快樂，能夠在明年有一個好的開始。同時也感謝大家對 TechBridge 的支持。
我自己喜歡看的技術文章有兩類，一種是分享一些實際的軟硬體技術，例如說教你怎麼用 Node.js 寫一個聊天機器人，或是怎麼用最新的 CSS 語法建造出酷炫的網頁效果等等。另外一種則是比較「軟」一點的心得分享文，例如說最近這陣子滿常看到被分享的這兩篇：接近 2016 年底的我是否有資格稱為資深工程師、技術人員的發展之路。
我預期大家在這週應該想要好好休息（其實我自己想好好休息），因此，就決定寫後面那一類型，來分享一下自己的心得感想。不過東想西想，身為一個工作經驗不到兩年的開發者，實在是很難給大家什麼「建議」，怕耽誤了大家。於是最後就決定來寫一篇自己在今年裡面體悟與學習到的幾件事情。
分享
「分享」一直是我很注重的一件事情，在每篇文章最底下的「關於作者」，我也寫得很清楚了：
相信分享與交流能讓世界變得更美好
為什麼我覺得分享是一件重要的事情？因為從我接觸程式開始，就受過太多人的幫助了。例如說小時候剛開始學程式矇懞懂懂，曾經去過那時候最熱門的程式討論區程式設計俱樂部發問，就得到很多前輩的幫助。或者是長大之後上 ptt 尋求職涯上的或技術上的幫忙，也得到很多回饋。
更別提工作上碰到困難一定會用的Stack Overflow，以及要做什麼新功能之前會先找有沒有別人寫過模組的Github。
這些資源都不是一夕之間產生的，而是靠許多熱心的前輩們一點一滴累積起來，才有著現在的樣貌。這也是為什麼我覺得分享是一件很棒的事情。當大家都樂於分享的時候，就可以形成一個正向循環：「A 接受別人的分享得到收穫 -> A 決定自己也要來分享 -> 更多人接受別人的分享 -> 更多人決定自己也要來分享」。
因為受到這些網路資源的幫助實在是太大，讓我下定決心自己也要當一個樂於分享的人，來回饋那些曾經幫助過我的人。
下面是一些我曾經分享過的心得文章（只列出幾篇比較多人看的），分散在 ptt 或者是我的個人部落格：
- [心得] 15家中小型公司、新創公司面試心得分享
- [情報] 免費程式入門教學(台北)
- [心得] 十年程式自學之路
- [教學] Line BOT API
- [教學] Facebook Messenger API
- [Javascript] Promise, generator, async與ES6
- Re: [請益] 入行不到一年，去新加坡發展好嗎？
當初的初衷不為了什麼，就只是為了分享而已。只是覺得自己在過程中有收穫，所以想把心得感想分享給大家。例如說我自己做完 Line BOT 的時候，就發現有一些流程如果自己探索，可能要花很多時間，這時候我就會想把心得寫下來，讓之後的人可以參考。
我會那麼堅持分享的另外一個理由，是希望「我之後的人，都不要再走一遍我走過的路」。這是什麼意思呢？例如說我要到新加坡工作之前，曾經在網路上查了很多資訊，確實有很多實用的，但也有一些是很難查或是根本查不到的。因此當我來新加坡之後，我就希望我能夠分享這些「我以前想知道卻沒有人分享」的資訊，讓那些像我一樣想找這些資訊的人有地方可以找到。
我覺得這個概念有點像這一個網路上流傳的故事：
This is a story about four people named Everybody, Somebody, Anybody and Nobody. There was an important job to be done and Everybody was sure that Somebody would do it. Anybody could have done it, but Nobody did it. Somebody got angry about that, because it was Everybody’s job. Everybody thought Anybody could do it, but Nobody realized that Everybody wouldn’t do it. It ended up that Everybody blamed Somebody when Nobody did what Anybody could have.
或者是 g0v 的座右銘：
「不要問為何沒有人做這個，先承認你就是『沒有人』」。
因為，「沒有人」是萬能的。
跳下來吧，跳下來當第一個，幫大家解決那些你以前碰過、找不到資料的問題，從此以後就不會有人像你當時一樣找不到資料了。
而且有時候分享也會帶來一些意想不到的回報，例如說你去面試的時候可能面試官會跟你說：「我好像看過你的文章」。或者是可能有一些程式相關的機構會找你去講課，或是一些新聞媒體網站的訪問等等。這些都是在寫文章的時候沒有預料到的。但還是要再三強調，如果你是為了這些額外的回報才分享的話，就失去了分享的初衷。初衷很重要，那是唯一能夠支持你長久經營下去的動力。
有些人會覺得：「我那麼菜，哪有什麼可以分享？」。但其實是有的，因為你總是會找到比你更菜的人。你學程式一個月，總是可以找到學程式 15 天的人，我甚至覺得程式入門這種東西，應該由「新手」來教「超級新手」，為什麼？因為那些新手可能一個禮拜前跟你一樣卡在迴圈，不知道迴圈到底可以做什麼，但是這禮拜他就領悟了。我覺得這時候是最適合教學的時機，因為他們還記得「當初卡住的那種心情」，他們是最懂你心情的人。
像我接觸程式這麼久，你問我當初第一次學遞迴的時候是什麼感覺，我真的完全忘了。接觸久了以後，寫程式就像吃飯喝水一樣，你問我怎麼吃飯怎麼喝水，我只能跟你說：「阿不就把嘴張開吃飯嗎？這個要怎麼教？」。
所以儘管你覺得你很菜，你還是可以試著寫下自己學習程式的心得，以及自己卡關的地方跟之後怎麼解開的方法，相信一定會對比你更菜的人有幫助。像我現在寫的很多文章技術深度也很淺，但還是幫助了很多人一樣。
廣度 vs 深度
技術的廣度跟深度到底哪一個重要（或者其實根本一樣重要），一直是一個爭論的話題。有些人覺得你知道的很多、很廣很好，代表各個地方你都懂一點，但缺點就是每一個地方都不夠深入。有些人覺得深度才是王道，才能成為某一個特定領域的專家，擁有獨特的技術洞見。
我可以很坦白地承認，我是一個有廣度沒深度的人，我之前寫過一年的 Android，有寫過一個即時通訊 App，也有維護並更新過一套公司內部的 SDK，並且導入熱更新的技術。可是如果你叫我去面試 Android 工程師，我還真的不敢去，一定被電得唏哩嘩啦。我可以獨立完成一個 Android App，這個決定沒問題，但如果你要問我一些更深的問題，例如說一個 Activity 被創建的整個流程，或者是某個 library 的底層實作，這些我全部都回答不出來。
所以你說我會寫 Android 嗎？好像會，又好像不太會。
我之前寫過一年的 Node.js，可以獨立做出一個後端服務，包括資料庫（MySQL）、快取（Redis）以及部署，Nginx 的設定我也不陌生，只是真的要用的時候還是要查文件就是了。可是如果你叫我去面試 Node.js 工程師，我也會被電得一塌糊塗，被問到 Node.js 更深入的問題的時候我就回答不出來了。例如說 Node.js 的底層實作或者是 this 代表什麼之類的。
所以你說我會寫 Node.js 嗎？好像會，又好像不太會。
其實對於廣度跟深度到底哪一個重要的這件事情，我到現在還是很迷惘。
因為我的確有體驗到廣度的重要性。例如說我現在雖然是一個前端工程師，但如果你真的只懂前端（HTML, CSS, JavaScript）的話，其實有很多問題你是解不開的。像是我最近寫的一個 Single Page Application，網址上面不想用 # 這個符號，而是想要長得跟正常連結一樣。
例如說原本的可能是http://example.com/#/home，我想讓他變成http://example.com/home，這個要怎麼設定呢？
因為我有碰過 nginx，所以我就知道說這個可以利用 nginx 來設，把那些路徑都導到index.html去就好了。但如果你根本不知道 nginx 在幹嘛，甚至不知道有這個東西存在的時候，這個問題對你來說可能就會比較難解。
有關廣度的話，我認為無論你做哪一個領域，都不可能對其他領域「一無所知」，至少要知道跟你有合作關係的領域大概在幹嘛，不然會很困擾。例如說做前端的就要懂一點後端、懂一點 Mobile。這樣在跟那些領域的工程師合作時才會比較順暢。
同時，我也有體驗到深度的重要性。
當你的技術深度不足時，有些問題是會卡住、解不開的。例如說你今天用 CSS 排版，用了一個套件之後發現有一個 div 的內容看不見了，但是把套件拿掉就出現了。如果你只會基本的 CSS，不知道那些 position, z-index 怎麼調整的時候，你就很難去解決這個問題。
又或者是我前陣子做直播，在 hls 的 player 上面碰到問題，發現有時候載入的情形很奇怪。我有嘗試過去閱讀播放器的源碼，但礙於我技術實力不足，以及對專有名詞跟整個播放過程不太理解，最後還是不知道要怎麼解決這個問題。
在面試的時候也有察覺到深度的重要性，或者說是一些「紮實基礎」的重要性。例如說面試官可能會問你「資料庫的 index 是什麼？」，我大概只能回答到「加 index 之後能讓查詢的速度變快」這樣子很淺的回覆。但基礎紮實的人能夠回答到有哪些 index，每一種的差別在哪裡，以及 index 在資料庫底層是怎麼實作的。
我自己一路走來，因為很愛玩一些有的沒的，所以技術廣度應該是還 ok，但技術深度就真的不足了。希望自己之後能走得更深一點，基礎打的更紮實。
小公司 vs 大公司
這也是在職涯選擇上一個討論度很高的話題，而我覺得這個選擇其實跟上面說的廣度與深度的話題也有點關係。
以我自己待過新創公司的經驗，進去之後就是你一個人可能會負責很多個專案（例如說同時負責 Android 跟網頁前後端，如果你有能力的話），這時候你就能拓展你的技術廣度，學到很多不同的技術。但是把時間跟資源分配在這麼多不同的領域上面，缺點就是深度不夠深，就可能像我剛剛講的那些，你東西寫的出來，但是回答不出更深的問題。
大公司的話，因為我自己沒有待過，所以只能猜測一下在做什麼，應該是專門負責某一個領域，例如說有一個專業的 Android 團隊，可能有五六個人，一個 Team leader、兩三個 senior 工程師帶著 junior 之類的。你被分到的可能是一個很小的功能，要照著大家訂下來的規則去寫 code，寫完之後要做 code review，測試沒問題之後才能上線。在這邊，你可能可以花一個月只去研究一些性能優化的問題。
我自從第一間是待新創公司，待一年多之後其實想換到大公司去工作。為什麼？因為我想體驗大公司的開發流程。在很多新創公司，開發都沒有什麼流程，規則比較鬆散。例如說我自己一個人負責那整個專案的話，我要不要寫測試、程式碼風格要不要統一，這一切都取決於在我。有也可以，但沒有也可以，沒有人會管你，但是也沒有人會給你一些建議。優點是非常自由，缺點就是沒有人帶。
所以待久之後，就會想體驗一下大公司的開發流程到底長怎樣，想要試試看跟別人分工，而不再是自己一個人做一個專案。有人可以互相討論、互相指點，彼此教學相長。
不過無論是哪一種類型的公司，我覺得最重要的還是「找一份可以學到東西的工作」。這個道理很簡單，你一天必須花八個小時在這一份工作上面，如果你在這份工作已經找不到什麼可以學習了，那你的成長就停滯了。雖然當個薪水小偷領這些薪水也很不錯，但我覺得你也必須考慮到你之後的職涯發展（除非這份工作你本來就是要養老用的）。要找一份學得到的東西的工作，你才能邊工作邊成長，對你自己的生涯發展也會更順利一點。
要真的痛過，才能理解
我之前有一陣子，每一天都會打開一些技術文章的網站，把前幾名都點開來看。那時候覺得自己學到好多東西，學到了大型分散式系統怎麼建的、學到了知名網路公司是怎麼管理軟體開發流程、學到了許多以前不知道的密技。可是我漸漸發現，自己好像其實什麼都沒學到。
那些技術文章如果每天看每天看，會有一種「我好像學到很多」的錯覺。但過一個月以後再問你當初看的那篇文章在講什麼，你還記得嗎？像我的話八成是忘記了，只大概記得文章的標題跟一點點內容而已。
覺得看很多篇技術文章就能學到很多技術的這種想法，我真的太天真了。實際上你把整篇文章看完，學到的可能只是作者理解的 30% 或者是更少而已。為什麼？因為你只是看，你沒有動手做，你也沒有實際碰過那個問題。所以那篇文章對你來說，就只是看著看著就忘記了。
我覺得在技術的學習上，「痛」是一件很重要的事。你要痛過，才能發自內心的想要解決那個問題，解決以後也才能真正的理解這個問題。
比如說今天你看了一篇文章在講大型搶票系統的伺服器架構與建置。你可能看完之後學到：嗯，有這一種建置的方法，下次可以來試試看。你就只學到這個「結論」而已。
可是 po 那篇文章的作者，他學到的是「一開始的搶票架構有什麼問題」、「改良後的架構解決哪些問題」、「兩者之間的優劣分別是哪些，適合什麼使用場景」。因為搶票系統的整個優化過程他都有參與，所以他絕對對這些問題刻骨銘心，可以講個兩三個小時。
我覺得看一篇技術文章你學到的可能只是表面，只是別人最後產出來的結論。你要真正理解的話，必須要自己跳下去動手做，實際去痛、才能領悟為什麼要這樣子做。
以我自己為例子，我剛開始的時候跟很多人一樣，不喜歡寫測試。我覺得自己手動測一測就好，幹嘛花時間去寫測試？但直到我「痛過」之後，我改觀了。因為有時候手動測的流程很繁瑣，你可能要打開頁面、登入、等個幾秒按按鈕之類的，每改一次 code 就必須要手動測試一遍。這個過程花了我很多時間，所以最後我就決定寫測試了。
或者是你每次都靠手動測試，但有一次某個流程忘記測到（因為你想說程式碼沒有改到那邊），然後晚上十二點接到 PM 電話說網站有嚴重的 bug，
只好半夜加班去公司修 bug，才發現是自己忘記其實改動的地方跟出問題的地方是有連動的，所以才會出現這種 bug。有了這次經驗之後，為了不要再半夜到公司加班，相信你會很願意寫測試的。
我覺得很多工具都是這樣，你用它一定是有理由的，是因為它有打到你的痛點，而且要夠痛，你才會願意去用。
利用冗餘時間
假如你負責的專案的需求已經開發的差不多了，於是你手邊沒有其他事情可以做，呈現一個很悠閒的狀態，你會做什麼？
- 滑手機
- 逛 facebook, ptt
- 優化程式碼
通常會選 1 或者是 2（我自己也是），但我最近選了 3。我會趁著沒有事情做的時候趕快看一下自己的程式碼有哪邊可以改進的，可以抽出來的部分就抽出來，並且自發性地幫我的程式加上 eslint 語法檢查以及一些簡單的 test。
以前累積下來的技術債，總有一天要還的，不然就只是越積越多，然後越難維護而已。我覺得應該好好利用這些難得的時間來對自己負責的程式做一些改進，不然等到下次再有這種時機，可能債已經很難還了。
維護履歷
我覺得定期維護自己的履歷也是很重要的一件事。一方面是可以減輕自己的負擔，不要每次要求職的時候才花很多時間改，可以在平常就慢慢累積慢慢改。另一方面也是藉由定期維護履歷，可以檢視自己過去這段時間做了哪些事情、完成了哪些專案。
在這邊建議大家在 Linkedin 上面定期維護自己的英文履歷，如果不知道該怎麼寫的，我提供一個我個人實際試用過，非常有效的絕招：參考強者你朋友的。這一招真的很有效，參考那些強者朋友的履歷，你自己大概就會知道可以怎麼寫了。
像是我的 Linkedin就參考一些我朋友的，把一些我覺得我也會的技能也抄下來，然後把看起來覺得不錯的格式也學起來，最後拼拼湊湊就完成了自己的第一份英文履歷。而且完成之後，還真的有獵人頭的寄信來邀約，可見英文履歷還是很有用的。
結論
就如同標題一樣，我是個資淺工程師，所以許多想法其實還很不成熟，很多的價值觀都還沒有確立，看的也不夠多。po 這篇文就只是希望能夠在年尾幫自己做個回顧，把到現階段為止的心得感想跟大家分享。或許以後我的想法會改變，這個很正常，那時的想法可能會比現在成熟許多。到那個時候，就可以自己來回覆這一篇文章，來幫自己解惑了。
最後，祝大家新年快樂！
關於作者：
@huli 野生工程師，相信分享與交流能讓世界變得更美好
