這篇算是對自己工作經歷的一些反省吧，我會跟當年剛成為工程師的自己說些什麼呢?
雖然我當工程師時間不算長也不算短，大概是六年左右，也待過小公司和大公司，
像是小公司，台灣分部人數只有 50 - 100 人；
上市大公司，全公司人數 500 - 1000 人；
國外公司有各個分部在不同國家，但倫敦分部工程師只有我一個人。
但如果早點知道這些要點，就會少浪費點時間在不重要的事情上，或是減少不開心的頻率，讓自己更能專心在個人發展、生活與工作的平衡上。
一、上班時交辦的事項完成後，在確認沒有其他事情要做時，可花時間精進自己
之前在某間公司時，我做完所有 PM 開的需求時，還會想辦法優化網站，比如模組化程式、或是主動開 tasks 改一些 PM 沒發現的 bug，因為我認為這個網站是我負責的，我應該全力把這個網站做到最好。
而且我還覺得上班就該全心全意都在工作上，不能看其他的資料，不然就是愧對公司；或是下班後都還在掛心事情沒做完，利用自己的私人時間蒐集資料，好讓我一上班時就可以快速開發；還會提前開發隔天、大後天、下星期、下下星期的功能。
短期來看，我對公司盡心盡力，也許我的努力會被看見而被加薪；但長期來看，對自己職涯發展並沒有太大幫助，對公司也不見得完全是好事。
我後來認知到 :
- 事情是永遠是做不完的，該休息就休息
- 與其一整天時間都投入在工作上，不如精進自己去看書看資料學技術、領導和溝通能力，有機會還可以引入相關方法進公司，對雙方來說都是 win-win
不需要覺得上班時完成自己負責的項目後，看其他技術資料是需要感到羞愧的。
二、工作進度、成果透明化
我之前常常覺得我完成的 tasks，不需要特別提出來講，只是因為我想做而已，甚至還覺得主管要我特別提出來講這件事情很做作 (主管表示 : 果然年輕人就是年輕人)。
後來才知道因為認知上的落差，之前在某間公司的 PM (PM 在菲律賓) 常常認為台灣工程師都沒在做事；而且我都喜歡做模組化這種工作，所以他們光看網站外觀是看不出來的，導致他們會看不出來工程師做了什麼，就覺得我們都沒在做事情。
事實上就是有做事就還是要適當的提出來講，該開的 ticket 就是要開。
所以我現在會 :
- 每周撰寫工作報告，包括 :
- 這週完成什麼 tasks
- 和什麼職位的人合作
- 有沒有遇到什麼狀況
- 如果 task 有 delay，是什麼原因，預估怎麼解決 (若是緊急的 task 須即時回報，而非寫在報告上)
- 若有成效數據則提供
- 下週預計做什麼
好處是可拿來當 performance review 時參考的資料，也可放在 LinkedIn 上，更能拿來當作談加薪的條件。
三、不用一開始就拼盡全力
這不是在說上班做事不要盡全力，而是要觀察狀況，
如果你一開始就做到 100，之後稍微做到 80 就會被人覺得你是不是在偷懶。
比如說像我之前每次都拚盡全力做到 100 甚至 120 (主動提出優化邏輯、介面等等)
但人也是需要休息的，不可能每次都竭盡全力，
所以有時候可能會做到 80，或是身體狀況不好可能只能到 60，
然後對方可能就覺得說 : 欸你之前不都可以做到，為什麼現在不行?
所以適當保留點餘裕還是很重要的。
四、在對的事情上負責任
之前在某間公司時因為 PM 說他不太清楚現在網站的業務邏輯、UI/UX 設計等等，
我就整理資訊分享文章給對方，甚至有時候還幫對方寫提案、想業務邏輯，寫到後來結果大部分都是我在寫，因為那時候是新創公司，本來工程師就會身兼多職，那時就覺得多學多做沒關係，反正多學也沒有壞處。
結果後來過一陣子發現對方提案還是都亂寫，然後說工程師都很閒沒在做事，我就不幫忙了。
現在我是看人幫忙，如果對方態度好我又有空，就還是會盡量。
你可以善良、你可以幫助別人，但你的善良不要被別人所利用。
如果你現在有正在忙的 project，有時候別人要求簡單的 task 比如換換 logo，你也許會順手做，但是如果對方要求還要改 logo layout，你會順手做嗎?
如果你有多餘時間，當然沒問題；但是記得這件事也是算一個 task，你的工作清單上也要把這件事列上去。
如果你忙到不行，還是順手幫忙換了 logo，不要為了別人也順手改其他相關事物，一個是你有更重要的 project 在忙，對方要求你做的 task 可能重要性沒那麼高；這樣你做了不但影響自己行程，也可能會讓對方誤以為你現在有空做更多，或是對方要求你改的地方，沒你想像中快可以解決。
五、勇於對於不合理的需求 / 時限說不
當主管 / PM / 客戶提出的需求或時限，你評估過後覺得不可行、執行上有困難、花費很多時間但效益不高、時間太趕等等。
不需要勉強自己一定要達成對方的要求，然後加班或用自己時間去趕出來，有第一次就會有第二次，然後就會有第三第四五六次，有可能最後趕出來還是不是對方要的，卻花了很多自己的時間。
把為什麼不可行的原因、疑慮的點和對方討論，商量出一個雙方接受且可行的方案
舉一個親身案例 : 如 PM 要求我隔天要上一個活動頁面要包括可以抽獎、顯示中何種獎項和實時顯示最新中獎人打碼 ID 和獎項，但時間實在太趕，預估其實本來要三天的開發時間。
如果對方還是不接受，常常要你加班或用自主時間做出來，請快逃
"有沒有什麼事我應該要做但沒做，或是什麼事情可以做得更好"
- 開發需求、欲達到之目的
有時需求方提出欲開發之功能，不見得是對方理解的能達到的成效，所以理解需求方想要達到的目的，可以更有效的釐清需要使用的技術、並提出如何可以做得更好的方式。
六、和主管固定每週 One On One
主管如果沒有跟你約每個星期 one on one meeting，可以主動跟主管約，定期拿到 feedback。
平常就可以準備一個記事，記錄 1:1 想討論的事。
免得之後想討論都忘記了；但不是報告最近自己做了什麼事，平常負責的項目和進度就應該透明化讓全部人知道。
可以問比如說 :
"我想要在下次評等升職，你覺得我還欠缺什麼能力? 我還可以朝向哪個方向努力?"
"團隊發展我覺得可以朝向 xxx 去解決 ooo 問題"
才比較不會面臨升職壓力時或是要求加薪時，主管才說其實他覺得你還欠缺什麼能力，也可以當作定期檢視自己。
七、工程師也需要溝通
不要再說工程師不需要溝通，所以想當工程師了；工程師要能 :
釐清問題
有時需求方提出欲開發之功能，不見得是對方理解的能達到的成效，所以理解需求方想要達到的目的，可以更有效的釐清需要使用的技術、並提出如何可以做得更好的方式。
同時也可以避免開發完成後，需求方才發現這不是他所需要的；還可以趁此知道公司目前的營運方向。
- 有 bug 出現時
這時候你可能需要要知道 bug 怎麼出現的，用什麼裝置、使用什麼瀏覽器上、版本是多少、如何操作的、什麼時候出現這問題的?
跟非技術人員溝通時，能把複雜的概念描述成對方可以聽得懂的
工程師之間很習慣用技術名詞討論，但當要解釋給非技術人員時要能把複雜的概念描述成對方可以聽得懂的，如果丟出一堆名詞看起來很厲害，但對方還是沒辦法理解時，其實對於專案進行也沒有幫助。
因為大家時間都沒那麼多，先回答如可不可以解決、預估花多少時間，對方想知道細節再跟對方說。
其實我本來遇到不熟的資訊時，都還是一律先看中文，因為會想說都已經不熟了，再看原文解釋不就更看不懂? 所以當遇到有人推我沒接觸過的領域的原文書時，我會排斥直接看。
直到某次解 bug 鬼打牆很久我才真心體會，網路上查資料查半天，真的比不上好好看官方文件；而且中文資料的錯誤率好高，有時候是因為有些詞要翻成中文就不是很貼切，而且看別人翻譯的文章又會跟本來的文件多隔了一層，就好像傳話遊戲傳越多人中間越會有資料遺失或缺漏。
這時候你可能需要要知道 bug 怎麼出現的，用什麼裝置、使用什麼瀏覽器上、版本是多少、如何操作的、什麼時候出現這問題的?
但回報問題的人不見得知道必須提供這些訊息，那你就需要想辦法問出來
跟非技術人員溝通時，能把複雜的概念描述成對方可以聽得懂的
工程師之間很習慣用技術名詞討論，但當要解釋給非技術人員時要能把複雜的概念描述成對方可以聽得懂的，如果丟出一堆名詞看起來很厲害，但對方還是沒辦法理解時，其實對於專案進行也沒有幫助。
因為大家時間都沒那麼多，先回答如可不可以解決、預估花多少時間，對方想知道細節再跟對方說。
八、在抉擇使用技術時，重點是可以為公司帶來什麼利益
雖然身為工程師會想嘗試各種新技術，但這就很看公司文化，比如上層願不願意讓你嘗試，除非你可以提出有利的證明說引入這個技術可以增加公司多少利益，不然想玩新技術還是自己回家玩比較快，當然或是你也可以跳到有在使用特定技術的公司。
在抉擇使用技術上重點是用什麼可以為公司帶來利益，而不是現在最新技術是什麼，毫無根據的持續引進使用新技術，有時候反而會造成維護麻煩。
九、任何情況下讓自己都可以保持冷靜
可能臨時接到很趕的案子；或是有時候需要直接面對客戶，遇到客戶一直打擾你的情況；或是遇到自己推上去的程式造成網站的重大問題 (先不論在上程式之前應該要跑過 unit test、code review 等等，因為就算經過這些程序，還是有可能會出錯)；
這時候可能會因為怕趕不上時限、客戶追你進度、怕被責怪或是自我批評而不能專心在開發或是 debug 上。
這時候先停一下，你可以 :
- 列出來要做的事項和預估的時間
- 和同事聊聊，也許會得到靈感，或更加釐清現況
- 或是稍微出去走個五分鐘，讓自己沉澱一下
十、自己解決問題的能力，尋求別人幫助的勇氣
自己解決問題的能力和尋求別人幫助的能力是個需要拿捏的中庸之道。
自己解決問題的能力
當你剛到公司時，也許還不熟悉流程時，你可以觀察其他同事 / 找公司內文件來看；
程式上有很多基本的下 console、查 stackoverflow 等的方式幫助自己，可以善加利用，減少問別人一些重複或網路上就查得到的問題。
尋求別人幫助的勇氣
你可能會不想麻煩別人，想要自己可以獨立解決問題，
這也許在做自己的 project 時可行，但在公司時有時限問題，不能一直卡住沒有進度，所以給自己一個時間區間，比如卡住一兩小時後向其他人求助。
十一、認知到大家沒那麼在意你
我之前常常在別人面前做事就開始緊張，導致發揮失常，
比如說要 pair programming 的時候，在別人注目下就會緊張到腦袋空白；
但其實大家都是比較在乎自己勝於在乎別人，當你回想的時候，你會記得自己表現不好的時候，還是別人表現不好的時候?
所以一時的表現不好也不用太在意，過沒多久就沒人記得了，放手去做反而還顯得比較落落大方，也可以得到更多反饋。
開會時對於 tasks 有疑問卻不敢發言時，與其怕被笑不如直接詢問確認需求與細節，比不問只埋頭做卻做出不適用的東西來得好。
十二、到處搜資料比不上看原文官方資料 10 分鐘
就這樣過了幾年，盡管我早就聽說過了要看原文、要看官方文件，但我都放在心上沒去實行。
直到某次解 bug 鬼打牆很久我才真心體會，網路上查資料查半天，真的比不上好好看官方文件；而且中文資料的錯誤率好高，有時候是因為有些詞要翻成中文就不是很貼切，而且看別人翻譯的文章又會跟本來的文件多隔了一層，就好像傳話遊戲傳越多人中間越會有資料遺失或缺漏。
十三、人生是段旅程
有時候會看到別人的成就而感到焦慮，比如誰找到國外工作、誰跳槽後薪水高了 20%、誰遇到問題比你快解出來、年輕的工程師比你還快升職、剛進來的人薪水比你高等等。
是的，在這個時間點，在大家的世俗定義上，他們的成就比你高。
人生就好像是一段旅程，在這趟旅程途中，會看到有的人走在你前面，會看到有的人走在你後面，有的人可能跟你差不多速度在行走。
走久了後，有時候會看到之前走很慢的人突然超越你，有時候會看到一直在自己前面的人突然慢下來，當然也有一直遙遙領先的人，也有放棄這趟旅程的人。
但重點不是為了要跟上某人或為了超越某人而往前，而是更專注在自己身上。
如果累了你可以停下來調整步調，就算看到別人走超過你也不用擔心，因為你有你自己旅行的方式，
甚至你還可以找可以一起旅行的伴，互相激勵抱怨前進；
你可以一邊漫步一邊欣賞風景，一昧往前走太可惜了對吧；
也可以快速通往你下個感興趣的景點，捨棄你不需要的事物；
但最重要的是能夠顧好自己，且穩定的往前走。
謝謝您的文章 收穫許多
回覆刪除不客氣! 很高興你有收穫
刪除