試想，24歲研究所畢業，就算是25歲投入職場，到了30歲，那個時候的自己是怎麼樣的自己?

前面提到，coding的工作某層面算是入手容易但是要精熟卻是不容易的一個工作。曾經看到一份履歷，工作年資五年，但工作的內容卻是重複在開發報表系統的工作。雖然有可能是履歷者本人自己的選擇，我們無從置喙，不過一樣，可以問問自己，真的想過這樣的重複生活嗎?

如果已經能做好時間管理，自己日常的工作也理論上切分出細節，能跟主管(利害關係人)達成工作的共識，自己的狀態上應該算是掌握住工作的節奏，然後有稍微多一點的時間可以運用才是。如果想讓利用這些時間，提升自己的技術，可以參考以下幾點我的建議﹔

1. 要有忍受孤獨的不服輸的態度。後面看完你就能懂了。

2. 學會做壓力測試。每次碰到應屆畢業生聊到專題時，我都一定會順口問一句﹔有多少人同時使用的經驗。學生時期寫的服務，多半以概念實作為主，並不特別講求實用性。但是到了職場商業，就不是這樣了。服務是設計給1人單獨使用，或者100人使用的，甚至每秒百萬流量等級的，基本上是完全不同的概念。自己的服務完成後，可以使用壓力測試的方式壓測看看自己所設計的架構能承受多大的流量，以及在高流量的過程中會產生什麼樣的服務行為，作為日後維護時的徵狀參考。

3. 學會寫log與注解 / 看別人的log與注解。如果是獨立開發者，通常在職業生涯初期都不太會在意log與注解。畢竟程式是自己寫，也是自己維護，有狀況時看著自己的code多少都有一些印象，要維護都不太困難。但通常自己超過兩年的服務，或者看別人的服務時，log的好壞就決定你後續處理事情的時間速度了。尤其在壓測與架設服務過程中，log能提供你明確的中段訊息，來判斷問題發生的地方來作快速除錯。

4. 學會重建工作所需的環境架設起來。應該聽得出來我的思維很重視流程。有一些團隊或者既有的工作，讓工程師只需要面對git，把程式commit上去後，後面的流程就會自動部屬到環境上去。在程式面的更新流程掌握後，誠摯的建議要學會把工作所需的環境能重建起來。重建環境有助於學習拆解服務之間的相依性，以及了解服務所需的周邊服務。了解這些幫助你能更全面了解整個服務的架構。

5. 學會調教你的服務。這個學習會牽扯的事情比較廣，但是當程式面的調整到了極致，要再讓服務容量再躍進，就必須要學會從系統面調整。舉例來說，如果是寫PHP的，就要更進一步了解nginx / apache 與 php 之間的關係，系統預設了那些參數可以作調整，參數與參數之間的關係等等的。當原本的服務有了基本的壓測數據後，就可以針對這些系統參數調教，進而比較改變的成果。

6. 學會監控服務。當透過壓測觀察到高流量時能知道系統異常的徵狀，那整體服務應該就可以先劃出一條預警線，避免系統全面崩潰。而這條預警線應該劃在哪個服務的什麼指標，這都有賴於前面的課題的落實與掌握。

7. 參與社群。我想要完成上述的修練，免不了會不斷地使用google搜尋相關的資料，會找到許多論壇，或者會在FB、TG等社群上發問討論，尋求解答。網路上有非常多的社群，線上線下的活動也不少，盡可能在修練過程中多參與社群的實體活動。一來有些議題的討論線下的面對面討論可能比較容易些，二來，嗯，不能讓你主管知道你在找工作.......

8. 學習分享知識。捧一下主辦單位的場，取之於社群，回饋於社群，把自己的學習歷程經驗紀錄回饋出來，讓下一棒的新鮮肝能有學習的管道，踩著前人的肩膀往前進步。

這個單元本來想寫，該練資料結構還是練演算法；是計算機結構還是恐龍本的作業系統，還是務實一點寫寫什麼LeetCode刷題技巧，我很難明確的說這些有用或者沒有用，書到用時方恨少，資訊本科的必修課還是有他的道理在。

「.....就像一個聰明人把房子蓋在磐石上；縱使風吹，雨打，水沖，房子也不倒塌，因為它的基礎立在磐石上。可是，那聽見我這些話而不實行的，就像一個愚蠢的人把房子蓋在沙土上，一遭受風吹，雨打，水沖，房子就倒塌了，而且倒塌得多麼慘重！」(聖經 馬太福音7章 24-27節)