https://medium.com/hulis-blog/4-years-review-7fb7edc52687
重點整理
當你懂的東西愈多，不懂的也會愈多。
文件及教育訓練
碰到問題時在常見問題裡面就能夠找到解答，完全不需要問到我。
時間久了以後我也慢慢可以歸納出問題類型，因此寫了一份文件，只要照著上面的指示通常就能知道問題出在哪，也幫他們科普了 SDK、API 這些名詞，希望能讓他們對這些東西有最基本的理解。
自動化與標準化
直覺地把重複性的東西自動化跟標準化，工程師不就是這樣嗎？同樣的 function 寫了兩次以後就要抽出來變成一個，冗餘的 code 就是要重構寫得更漂亮。
時間就是資源
時間就是資源，節省了時間就增加了更多可利用的資源，從這些重複性極高的事情中解放以後，工程師就有更多時間去做其他更有價值的事
面對未知事務的態度
在找工作的時候，不要自己把自己刷掉。若是不敢投的原因是覺得自己能力不足，背後的可能有兩個：實力夠但自信不足、實力真的不夠。 但我要怎麼驗證到底是哪個？ 我無從驗證。 一但拒絕了面試的邀請，我就永遠不會知道答案是什麼。所以沒什麼好不答應的。若是我真的沒實力，在面試時對方自己會把我刷掉；若其實是自信問題，那我就賺到了，證明我其實比我想像中的更有能力
單兵作戰 VS 團隊作戰
一個人的好處就是想玩什麼沒人管你，你今天想用最新最潮的 library 也行，寫一堆爛 code 也可以，也不會有其他人看到你的 code。壞處就是雖然自由度極高，但久了之後會開始懷疑自己：「這樣做真的好嗎？有沒有更好的做法？」、「我寫的 code 真的可以嗎？會不會其實都是爛 code」。 沒有團隊的後果就是如此，沒有人跟你討論或比較，完全不知道自己現在的能力到哪。很快地察覺到這件事情以後，我開始加強自己對「深度」的要求。若是碰到問題，就要盡可能追根究底，試圖完全搞懂問題的成因與解法。理解得越透徹，能力就越強
Account
- 有新功能的時候要跟 PM 先開會，討論規格並安排時程
- 安排前端的時程並為其負責
- 把 ticket 分給同事，決定分工
- 每兩週與 PM 開一次 sprint planning meeting，決定這個 sprint 要做什麼
- 每兩週與 PM 開一次 grooming meeting，來討論 backlog 裡面的 ticket 總之在這個職位上，溝通的部分會比以前多很多，我就是前端組的窗口，有什麼事情都會先來找我。
重建與重構的心態差異
之前在 PTT 聽到一句話很中肯：「很多工程師只會重建，不會重構」。有時候重構不一定要全部需求凍結，只為了排一段時間給你專門重構。從日常的修 bug 開始，就可以慢慢把看不順眼的小地方改掉，就算只是一個 function 也行。
就這樣慢慢改著，專案也變得愈來愈穩定
也因為要處理 SEO 問題實作了 Server Side Rendering，在增進效能上也花了不少心力。
實力
技術能力是工程師的基礎，也是自信的來源。如果沒有持續進步，那就是退步。我的技術能力在開始工作以後成長幅度才開始增大，因為在工作上你不得不把 bug 解掉，碰到的專案規模跟自己的 side project 也完全不同。
我一直都相信是金子總會發光，有實力的人才不會被埋沒。尤其是在這個網路時代，你可以利用各種方式讓其他人看見你。
無論我之後是繼續當個工程師還是慢慢走向管理職，都不能忘記技術能力是工程師之本。要讓別人服你靠的不是名氣、經歷或是學歷，而是能力。
溝通
技術能力很重要，但溝通也同等重要。不只要學會講，也要學會聽。
我每次在 ticket 裡面回覆問題時都盡量寫得詳細，雖然乍看之下耗時，但其實是最節省時間的方法。
若是講得不清不楚，還要再等對方回覆看不懂的地方，然後你再講得更清楚，那為什麼不一開始就講清楚就好。
若是在專案開發上碰到我覺得不合理的地方，我會直接說出我的理由以及我建議的解法，但要不要採用我交給 PM 來決定，因為我覺得那是他們的專業。
我覺得很多問題不是產品問題也不是技術問題，是溝通問題，溝通的兩方根本沒有在同一頁上。你講你的他講他的，最後各自堅持自己的想法互不退讓。但重點是，你們其實是有共識的，只是溝通的方式或是方向讓雙方都感受不到這件事。
想改善的話可以在網路上開始免費教一些新手或者是回答問題，你只要能夠理解問題以及用他聽得懂的方法回答，你就成功一半了。
留言