自駕車暑期實習—期中反思
經過六週的遠端實習，我學到的六件事。
為期十二週的實習正式邁入後半階段，在第七週的禮拜一，也向組上的人呈現了一個期中報告/DEMO。蠻喜歡我在做的project，所以工作起來大多是興奮的（一半一半啦，不想做的時候就真的看到code就倒胃）。同事非常幫忙我，即便是全程遠端的實習，我也學到不少。
欸，因為有NDA，不會講到技術內容；內容比較偏向，一個好的工程師該具備什麼樣的能力。又或者說，那些我本來知道蠻重要，但平常在學校用不太到，一進職場發現真的、真的、真的非常重要的能力。理應在學生時期強迫培養。
以下依序把我認為最重要的事情一一闡明。
壹、對你所在的產業有個purpose
最近宅在家才追了這部影集…我真的陷到無敵深淵去，這劇情真的太過癮。
回歸正題。一直都知道進了一家公司，你不能只抱持著為了賺錢而去上班的想法，因為你會做得不愉快。況且，這樣的想法會讓你用最消極的態度去面對你的工作，而我不相信這樣的心態能把工作做得多好。
長時間每天朝九晚五的做同一個project，如果你不會心生厭倦，那你可能很奇怪。就算你一次必須負責幾個project，當每天一起床就只能一直寫code，久了還是有可能對這件事失去熱情。再者，活在現今的世界甚至有可能必須Work From Home，除了每天面對一樣的project，還得每天面對一樣的工作/休息環境。
目前的我正是符合以上所有條件的碼農。天天在家工作，天天面對同一份project，天天坐在我的電腦桌前（下了班也繼續在同樣的電腦桌前放鬆、做自己想做的事）。如何維持我的工作效率、每天持續產出的動力，便成為一項困難的挑戰。
剛開始的一兩個禮拜有新鮮感支撐著，每天起床都迫不及待想知道今天會踏上怎樣的旅程；第三個禮拜以後，開始感受到乏味。我便開始思考，當初是抱持著什麼樣的初衷，想踏進自駕車這個領域。是，我心中有個未來的自駕車世界藍圖，而要實踐這個理想藍圖，我必須即刻起慢慢培養這方面的知識。了解現今產業上如何解決每個環節、觀察整個自駕車部門是如何分工合作、試圖找尋所有我對這個產業未知領域的解答，全部都是我所必經的過程。而再度確立我心中所嚮往的藍圖之後，我成功說服自己開始工作。
動工以後，我覺得重點就不再是尋找動力來源。如果你真喜歡你的領域，應該會享受整個過程，基本上就是喜歡工作（真m）。我開始愛上我的project，過程中會有枯燥、bug底不出來的各種時候，但熬一個夜晚解決他之後伴隨而來的成就感，便可以繼續鞏固著我做下一個feature。我認為這就是個健康的循環。
這份對產業的purpose會支撐你對工作的熱情，並且在這瞬息萬變的科技時代，提供你持續學習的動力。缺乏這個purpose，便無法成為一個好的工程師。對這件事有熱情，才會讓自己的腦袋有持續的input，這nerdy的職業才能細水長流。
貳、先求有，再求精
放下完美主義，立地成佛。
這是所有業界跟學界最大的差別吧。在學校，我們喜歡看到嚴謹的數學推導、理想化的解法、能夠寫出一篇論文的演算法；而在業界，講究的是成果。開發產品要快，才有競爭力；初步得到的解法如果能work，先不要求optimize，而是要先讓整個pipeline end-to-end都能跑起來。
一直都隱約知道這個道理，但我還是在這次的實習經驗裡著實震驚了。拿到我的project題目的第一個週末，我死命地讀了幾篇相關paper，並且整理出一套我覺得會work的超複雜pipeline😇（想起來真是自討苦吃，那整個流程不知道要implement多久）。禮拜一興高采烈地分享我的手繪圖示，解釋整個流程給組裡聽。他們聽完之後，一致跟我說先用最最最簡單的方法做，讓整個pipeline跑起來比較重要。
我聽了一位組員提供的簡單解法之後，心想：哇噻，這我怎麼沒想到…同樣的問題，我花十步想要把它解出來，而其實有個簡單的解法一步就能完成。也許那個方法不甚完美，不會讓你變成state-of-the-art，但在業界有產品才是最重要的吧。
參、責任制下該抱持的態度
大多數現今的軟體公司應該都是責任制，也就是彈性上下班，只要你把你份內的事情做好就行（當然還是有傳統公司例外，這邊就不討論）。再加上work from home，幾乎是沒人看得到你在幹嘛，我就承認我白天常常在耍廢，到了半夜突然有靈感，才卯起來狂寫code。
剛開始我認為自己有點消極，每天的心情有點像是想把當天的任務趕快做完（重點：只把當天任務做完），就可以下班耍廢看影集。可能是我骨子裡很討厭被規定要工作的感覺，這種態度似乎會讓我一天比一天更消極，畢竟這比較像是被動地工作。
後來我做了不同的嘗試，每天永遠做得比要求再多一點，一點點就行。這樣的好處在於，我有種重新找回主導權的錯覺，因為那份多一點的工作，是我自己給自己的。人又有種莫名的虛榮，每天做得比預期多一點，就自己暗爽（馬斯洛自我實現需求的概念）。
所以如果你也討厭被束縛住的感覺，不妨嘗試看看這個更m的心態，每天多工作一些些：）當然，前提是你覺得你做的東西很有趣，才會促使你想要多improve一個小地方、多增加一個小功能。
肆、如何在一個超大project裡使用版本控制系統
這邊就舉git為例（我也只會用git）。相信大家一開始學git，都只是為了交作業在github上，或是為了把code放在github讓履歷好看點，因此只會三招：
git add .
git commit -m "commit message"
git push當然，開始做group project，可能三、四個人，大家終於願意開branch了。結果最後要交作業的時候，還是會有人把code先統一傳給某個人，讓他統一上傳，或是即便大家各自有branch，最後也是手動merge，沒有利用到版本控制系統的核心價值。
其實我原本以為，我因為在CMU的capstone project裡算是負責統整整個repository的人，應該算是對git有些合作上的經驗了。殊不知看見公司裡龐大無比的code base之後，顛覆了我整個git workflow。
上面是我東查查、西查查、東問問、西問問，最後統整出來的workflow。也許對很多software engineer來說是習以為常的東西，但我就菜：）第一次待大公司，才強迫自己學會這些技能，實在太實用了。基本上就是，你從master開一個feature branch，你有定時commit的話，時間在走，樹應該要長。與此同時，master branch應該已經不知道長到哪裡去了（汗，所以用點點點來表示中間有幾千個commit）。因此，當你做完feature，想要merge到master時，得想辦法讓岔開的樹重新找到他們的共通點。
第一步，先把自己的commits squash到只剩一個紅點點（否則你等等rebase到master就要solve一樣的conflicts五次）（欸我不是故意中英夾雜，相信各位懂）。
第二步，把自己的branch rebase到現在最新、遙遙領先你的master，因此你只會ahead of origin/master一個commit，然後就很好merge了。
總之這真的很重要啦，我覺得平時在學校做project就應該強迫自己用merge request，而不是組員間把code傳來傳去或是任何非標準的workflow，因為這種小技倆在超大project裡都無法使用。
伍、C++有多麽重要
大一計程第一堂課，老師說：C++真的很重要。
學生心裡想：喔是喔。
哇乾，真的真的真的有夠重要。在現今Python氾濫的時代，大家為了求快，可能第一時間都會想用Python把一個小東西寫出來。不過，Python惡名昭彰的記憶體管理（現在還惡名昭彰媽？我其實沒在follow，有錯誤拜託跟我說），是很難讓他成為一個產品的。大部分的公司都還是需要像C++這種比較低階的語言，來有效地控制整個產品的記憶體用量，並且達到加速的效果。
如果你跟我生在同個年代，還跟我差不多同時修C++的計程，之後就沒再怎麼碰的話，那我跟你說，有得惡補了：）到處去逛逛有open source的大型C++ project，應該不難發現多了超多新的語法、用法，都是我大一學C++的時候還沒普及的東西嗚嗚。C++11以後（泛稱modern C++）真的多了一堆看不懂的東西．．．而且大家都在用了嗚嗚嗚（是不是我太笨）
總之，我覺得找個時間把這些新的概念補起來是非常必要的。當然，那些你從未了解透徹的inheritance, virtual functions, const也都要複習複習（為啥覺得我到現在還是沒有完全搞懂==）。
陸、平常多碰不熟悉的tool
每間公司一定都有自己一套最常用的軟體，不管是電子信箱、專案管理系統、版本控制、debug tool、視訊軟體、document platform，每間公司都不會一樣。
我覺得平常如果強迫自己偶爾換換tool，多去碰自己不熟悉的軟體，會有助於on board。一來你可能剛好用過公司使用的平台，二來你常常碰新的東西，也會讓你更容易適應新的工具。雖然說要上手也許都不難，但多學點工具也是多多益善。
以我淺薄的知識舉些例的話：docker、git、 好用的code editor（學會在各種function跳來跳去、學會快速在一個大project裡找到你要開的檔案、學會找到一串特定的string出現在哪個檔案哪一行）、 project management tool（像是Trello、 Jira這些）、 markdown documenting。感覺這些都不是學校會教的東西，不過都很實用，所以自己有空學學蠻不錯。
結語
我講完了，這都是我的想法啦，也不一定對。六週後，等整個實習結束，再來更新下學到了什麼好了。
