00如是說

Photo by Kelly Sikkema on Unsplash

剛好最近自己在鑽研「Design Pattern」跟「Design Principle」,原本只是打算寫在自己的 Notion,但想想既然都要寫了,就把這系列分享出來給大家好了!而且這種主題討論性本來就滿大的,也希望如果有高手有不同的見解可以多多跟我交流一下!

什麼是「迪米特原則」?

  • 一個單元對其他單元的了解應該有限
  • 一個單元只能與其直接的朋友交談,而且不用知道太多
  • 一個單元不應該和陌生人交談

上面這些特性文鄒鄒的,想必大家第一次看到也看不懂(因為我就是哈哈),下面會詳細解釋一下,其實說穿了就是想要降低對象與對象之間的「耦合度」。

「對象」:這裡的對象不僅僅是針對「類」,「函式」跟「模組」也是。
「耦合度」:耦合度在說的就是兩個對象之間的「緊密程度」,如果兩個對象耦合度太高就會造成「可重用性」、「可維護性」的困難,試想一個對象跟太多對象相關聯又關聯太深的話,改每一行 code 都心驚膽顫會影響到其他功能的對吧?

這裡附上百度上面的解釋

  1. 以參量形式傳入到當前對象方法中的對象
  2. 當前對象的實例變量直接引用的對象
  3. 當前對象的實例變量如果是一個聚集,那麼聚集中的元素也都是朋友
  4. 當前對象所創建的對象

任何一個對象,如果滿足上面的條件之一,就是當前對象的“朋友”;否則就是“陌生人”。

--

--

Photo by Milad Fakurian on Unsplash

不知道大家有沒有過這種經驗,好不容易把一個知識或技能摸索地差不多的時候,又發現汪洋大海的新知識,怎麼學都學不完覺得好累…。

隨著年紀增長,常常會覺得如果停下腳步是不是會很快地被淘汰?尤其是在「工程師」這個領域。人生也因此一直保持在一個高度緊張的狀態,後來我發現原來有一個名詞可以形容這個狀況,那就是「知識焦慮症」。

而伴隨著「知識焦慮症」,還有另一個症狀如影隨形,叫做「閃亮症候群」。由於自己也身陷其中,所以想來分享一下自己目前是如何試著去調適,以及記錄一下此時此刻自己的心理狀況。

什麼是「知識焦慮症」?

在現在這個網路資訊爆炸的時代,各種知識隨手可得,你可以足不出門就學習完一份完整的知識,只需要你家裡有電可以讓你用手機或電腦即可。

而所謂的「知識焦慮症」,指的就是面對現在龐大的資訊量,你害怕自己跟別人落差太大而卯足全力去學習,但卻發現時間根本不夠用,陷在一個「東西太多卻又沒時間學的狀況」。

嗯?這樣聽起來患有這個症狀的人都很有上進心呀!有這麼嚴重嗎?

這其實是一個很嚴重的惡性循環:
發現很多知識不懂怕跟不上其他人 ➡ 定了一個時間拼命學習 ➡ 好不容易拼命學完發現還是一大堆不會 ➡ 覺得倦怠想冷靜一下自己 ➡ 經過一段沉澱覺得自己還是不能耍廢 ➡又發現很多知識不懂怕跟不上別人 ➡ 定了一個時間拼命學習…永無止境。

上述可以發現其中是帶有很多負面情感的,即使外面的人說你多厲害多厲害,你還是覺得自己不足,甚至深怕哪天被拆穿自己只是個「紙老虎」。

在繼續深度討論之前,我想先來提提另外一個因為知識焦慮症而引發的「閃亮症候群」,都有些概念之後再來分享我自己長久以來摸索的調整方式。

什麼是「閃亮症候群」?

閃亮症候群指的是你對於新事物感到好奇,而一直改變你的目標,無法專注在同一件事情上。

這會導致什麼狀況?

我會分成兩種情形
1. 不同的目標一直切換(一下想做工程師、一下想做 Youtuber)
2. 同一個目標被不斷延伸(要學 A,在 A 的相關文章看到 B 跑去學 B,又在 B 的文章看到 C 又跑去學 C…。離自己的主要目標越來越遠什麼都學一半)

這裡我其實想針對的是自己當「軟體工程師」發生的第 2 種情形來做詳細討論。

但稍微提一下第 1 種的解決方案我認為就是:「保持樂觀、不輕易放棄。

「知識焦慮症」以及「閃亮症候群」的相關性

針對「閃亮症候群」,我們先來假設一種狀況好了,今天我們想學習怎麼「優化前端效能」,我們就去看了相關的技術文章。

看了相關技術文章之後我們發現了「Lighthouse」評分套件,就去看這個是什麼東西。

再來你就會發現這個其實可以做自動化跑分,也就是「Lighthouse-CI」,你就開始去研究。

又是一個再來,你就會發現自己對「CI/CD」不熟,跑去研究相關語法。

最後,你就會發現 「CI/CD」自動化部屬還可以配合「Docker」搞一些事,你就又開始研究 「Docker」。

你在一天之內非常快速地從研究「優化前端效能」這件事變成在研究「自動化跟 Docker」,可喜可賀。

然後很不湊巧你又沒辦法馬上理解 Docker 是什麼,你就會發現你今天好像什麼都沒完成?時間好少!➡ 知識焦慮症起手式開始。

嗯~曾經我也常常這樣的,甚至現在偶爾也會,但我在領悟一些心態跟方法之後,這些狀況有了些微好轉,因此想分享一下給大家。

解決辦法

  • 訂目標的迷思
  • 利用行事曆 + 上一些彈性時間按表操課

我們當然知道要做一件事情之前,訂立一個目標會比較好達成,但你如果對於完成這個目標「所得到的回饋期待感太大」的話,反而會造成反效果。

這是什麼意思?

小明:我要在半年內學好 Html、CSS、Javascript 這樣我一定可以找到好工作!從現在開始拼命!

結果半年過去了發現自己不過跟其他人差不多而已,又看到一堆框架要學。

小明:再三個月!我把 Vue 或 React…框架學好!一定可以找到好工作!

時間又過去了,沒想到學這些框架不過只是拿到門票而已,運氣不是太好,還是找不到理想的工作。

小明:唉!怎麼學都學不完(知識焦慮症)!轉職根本是騙人的找不到好工作啊!東西這麼多是要怎麼學得完…。

看完這則故事不知道有沒有人產生共鳴呢?其實這也不是新人轉職才會遇到的問題。每次當你突破一個階段,就會發現還有跟山一樣你觸碰不到的高手跟高深的技術等著你,檯面上有名氣的是一群,檯面下雖然沒有名氣但也是怪物等級的也是一群,於是又開始了知識焦慮循環。

接下來說說我自己是怎麼去調適的,但在這之前先推薦大家看看『原子習慣』跟『複利效應』這兩本書,會對人生有一些不同的想法。

關於訂立目標,我認為沒有什麼是「一定」,認真學習幾個月之後一定會怎麼樣嗎?沒有!社會是殘酷的!很有可能你所期望的什麼都沒有!這很有可能導致你灰心喪志,又想放棄去找別的事情來做(閃亮症候群)。

針對這個問題我們可以換個心態來思考,雖然目標沒達成,期望的沒發生,但真的什麼都沒有改變嗎?怎麼可能!你累積的東西都在你的大腦裡慢慢發芽!

今天即使你灰心喪志了,沒辦法再給自己那麼長的時間去再拼一次。沒關係我們先把時間縮短,不要給自己的目標有太大的期待感,我們抱持一個心態:「就算我每天只花 10 分鐘專心學習,累積起來也是可怕的知識量,每天 10 分鐘一個月也 5 小時了,叫你現在專心學習 5 小時你會覺得很短嗎?其實滿長的對吧!」

當你有了這個心態,我就算每天只花很少很少的時間學習,自己其實都還在實際進步,那就算定的大目標沒做到又怎樣!我還是累積了我的知識為下一次做準備,沒什麼好怕的。

就算看到一堆東西不會又怎樣!我現階段有一定要會嗎?不會的話有什麼很大的影響嗎?我今天寫前端,人家都說工程師應該要通才,我居然不會任何一個後端語言…,那又怎樣!我再每天安排短暫的時間去給他累積起來就好了(當然你有辦法花更多時間是更好囉!),我明天後天甚至下個月沒有馬上學起來也不會影響我現在的工作,我只要有每天花時間往前邁進,不要停留在原地就好。

這是想解決我剛說的,你要學東卻一直延伸學到西去了,這時候「Google Calendar」是一個很好的東西,我知道很多人會用「子彈筆記」,但其實用什麼都可以,看自己習慣就好。

會選擇「Google Calendar」是因為「子彈筆記」我嘗試了一下發現有很多我想要的功能人工做不到。

第一是「提醒」:
他不能讓我設定什麼時候要自動提醒

第二是「重複事項的攥寫」:
假設我每週一、三都要在晚上 21:00 學習半小時的英文,手寫我就必須在每週的一、三位置一直寫一直寫…(也有可能是我沒有想到好方法 😆),「Google Calendar」可以自動幫我設定重複排程。

第三是「空間配置」:
常常要增刪改就會造成頁面空間不夠,而且刪改也滿麻煩的。

第四是「速度」:
時間很重要,打字比較快XD。

至於我是怎麼排定的呢?我會建議每天都有一個主要目的時間 + 上一個彈性時間。

比如以剛剛的例子,今天 13:00 ~ 16:00 想來研究一下「前端效能優化」,我可能會這樣排:

  • 13:00 ~ 16:00 前端效能優化
  • 16:30 ~ 18:00 彈性學習時間

這樣做有什麼好處?為了就是解決無止盡延伸下去的問題。

我今天在看「前端效能優化」,一路看到「lighthouse」我就應該先踩剎車了,因為現在我的目的是研究「前端效能優化」而不是後續那些「CI/CD」甚至是「Docker」。

但你說看到新東西就學哪有什麼不好,對呀!看到新東西想學當然好,於是後面的彈性學習時間就派上用場了。

我們可以利用後面的彈性學習時間來補足後面的「CI/CD」跟「Docker」。

總歸一句就是:「不要讓你的目標模糊了」。

以上大概是自己個人的小心得,但每個人價值觀不同,如果有人看了這些覺得有幫助的話,我會感到很欣慰能夠幫助到你(畢竟要寫這種心態的文章我覺得滿難的XD)。

那如果有人覺得我說得不對或是有更好的辦法也歡迎跟我交流交流,說不定我也可以因此受到幫助。

謝謝大家!

--

--

Photo by Emily Morter on Unsplash

安安大家好!前陣子有點忙,不小心使用了「富堅之呼吸 — 斷刊之術」😂。趁這陣子有點時間復刊,不然都快忘記怎麼寫文章了哈。

最近思考了一下,想試著多寫一些不僅止於前端的文章,剛好自己也都有持續在精進 CS 相關的知識(非本科的哀傷 XD),就寫一些這系列的文章好了。

關於「直譯」、「編譯」的差別已經有太多鬼之神人分享了,但「半直譯半編譯」就比較難找到相關的說明。因此想試著用白話一點的方式解釋一下自己研究下來的心得,有說錯的地方再麻煩各方高手提點!

一開始,我們先把程式碼大致分成三種:

  • Machine Code(機器碼)-電腦在看的
  • Byte Code (字節碼/中間碼/位元組碼)-編譯完介於上面跟下面之間
    機器跟人都看不懂
  • 高階語言(Java、Python…等你所知道的那些語言)-人在看的

知道「編譯式語言」跟「直譯式語言」是什麼的人,相信也都知道 Machine Code 跟 高階語言 的差異了。

但問題來了,那 「Byte Code」 呢?。

這就跟我們今天的主題有關了。

半直譯半編譯

其實說破就是想要同時擁有兩者的優點:

  • 直譯之「跨平台
  • 編譯之「速度

如果我一開始就針對各家 OS 編譯成 Machine Code 的話,不就沒辦法達到跨平台了嗎?

又如果像 Javascript 那樣只透過 V8 引擎的直譯器解譯的話,就會得不到想要的速度

因此我們先搞一半就好,我一樣進行編譯,但我不編譯成 Machine Code,而是先編譯成 Java Byte Code。接著再透過 JVM 直譯器解釋成電腦看得懂的 Machine Code(因此你要在電腦執行 Java 的話,是一定要裝 JVM 的唷)!

可是這樣雖然達到跨平台,但後續還是有直譯的程序啊!速度一定會被拖慢的對吧?— 是的,這就又牽扯到「JIT 即時編譯」了。

簡單說明「JIT」就是把重複很多次的 Code ,編譯成 Machine Code 之後先 Cache 起來放在 Memory,下次就可以直接執行。

然後…就結束了! 謝謝各位😂。

--

--

Photo by bruce mars on Unsplash

安安大家好!這次想說的主題相信是很多想轉職軟體工程師都會有的問題,至於為什麼想寫呢?因為我自己也曾經有這個疑慮,而寫程式寫到現在也算是有點心得,就來分享一下我對於這件事的看法。

本人能力

一開始就先來說說我在學程式之前,英文能力到底如何,如果以「多益」來看的話,我當時大概就落在 300 ~ 400 分之間吧(大概國小到國中程度?),應該是算偏差了。

在這個基礎上,我也是順利成為工程師了,因此要我先給出結論的話,我會先給出第一個答案(為什會是第一個後面會說明):

「不用」,如果你正在前往成為工程師的路上,糾結要先學寫程式還是先學英文的話,那我建議你可以下定決心開始先學程式了。

不過話雖這樣說,大家也不要高興地太早,我說不用先學英文是建立在「你至少對英文是有基本的概念的」,如果你連 A - Z 或是簡單文法都完全不懂的話,那你程式絕對會寫得很痛苦…。

為什麼會說不用先學英文呢?

因為程式會用到的 keyword 你寫久就背起來了,漸漸地就知道這個是拿來幹嘛的,比如說:

  1. 「for」:迴圈會用到。
  2. 「if」:如果怎樣就要幹嘛。
  3. 「return」:回傳。

上面看到的單字不管在哪個程式語言都會有機會看到,我就算不知道它翻譯過後是什麼意思,我也知道怎麼用它,而用久了也就知道它的意思了。

所以寫程式還真的能學習到很多單字 😂,但你說寫程式久了英文就會變很好嗎?抱歉還真的不會,小弟我認識的很多工程師英文也都滿差的。

照這樣說,根本就不用為了程式學英文了對嗎?

No!No!No!很重要所以講三次,英文能力跟程式還是有很大的關係的。

到這裡有沒有人覺得:「你很奇怪耶!前面都說寫程式不用先學英文,現在又說英文跟程式有很大的關係!」

前面我也說了,我先給出「第一個答案」,為什麼是第一個答案呢?

英文,並不是短短幾個禮拜或幾個月就可以拉上來的東西,而寫程式也不需要非常強的英文能力,因此「如果你是一個正糾結要先學程式還是先學英文的人」,等到你把英文學起來才去學程式的話,你是要花多久時間才要準備開始學程式?你的主要目的是寫程式啊!而且你能保證你在學英文的路上不會半途而廢嗎==?程式都還沒寫就先被英文搞到放棄了。

所以才會建議說你如果正受這個問題困擾的話,就趕快去學寫程式別再想了。

再來就要說說為何我後面會說英文能力還是對程式很重要,這也是我最主要想寫這篇文章的主要原因。

雖然英文不用很好就可以學程式,但英文好絕對可以讓你在寫程式的路上順遂非常多。

在實務工作上,你一定會遇到很多問題是自己沒辦法解決需要上網查找資料的,這種時候查找英文文章絕對是比你只找中文還快找到答案,尤其是在程式圈很有名的「Stack Overflow」,連發問都要用英文,如果真的找不到答案想問問題,這時英文能力不好可能就連發問都做不到,

而且如果你是一個技術狂熱者,很喜歡學習新技術,如果這個技術才剛出來不久(或是在亞州還沒那麼流行,尤其矽谷的技術總是比台灣這邊快 1 ~ 2 年),那麼中文文章根本是少之又少,這時候看不懂英文真的很吃虧(我自己就是遇到這個困擾所以卯起來學英文中...)。

因此如果你已經踏入程式圈,而且也有餘力學習語言,在考慮學習英文對自己幫助大不大的話,我絕對是推薦你去把英文學好的。

當然如果你不在乎對程式有沒有幫助,就只是有興趣想學英文那也是可以啦 😂 😂 😂。

結論

因為自己當初也是有這個困擾而且本身也是一個英文不太好的人,一直到最近也算是對這件是有些感想,就想說寫出來看看能不能幫助到一些正在迷惘的人,大致上就這樣啦!感謝大家閱讀XD。

這篇有點短呢。

--

--

Photo by Juan Rojas on Unsplash

安安大家好!!千呼萬喚始出來(其實只有我自己在喚),終於有時間寫下這系列最後一篇文章了 ,距離上一篇都快要一個月了哈哈!😂。

不免其俗地,這邊先附上前兩篇的連結:

這篇主要會分享一下當主管到現在的一些感受,以及這幾年瘋狂寫程式下來的一些心得。

比如說「我個人認為要進步的話,應該要保有什麼心態」、「個人開發以及團隊開發的差異」,然後也想順便分享一下面試的心得。

先從剛到台北的時候說起吧,上一篇文章最後有提到要來台北帶團隊,想當然,第一步就是要先建立團隊了。

這裡順便提一下,由於當時我也是管理初心者(就是剛進入遊戲,一出村莊就會不小心被咬死那種),因此一開始我們是雙主管制度的,就是有兩個主管的意思,避免一個人太累。

那剛開始,最讓我不安的,我想就是面試了。

很奇怪吧?我明明是面試官,是有什麼好害怕的?

因為沒有什麼經驗,害怕的不外乎就是:「我應該要問什麼?」、「會不會面到一半無話可說?」、「怎麼決定要不要錄取?」,而且實際上,也真的有幾次面試面到一半腦袋一片空白,場面就這樣乾了一陣子。

經過幾次經驗之後,我冷靜下來,並且像一休和尚一樣在頭上畫圈圈,畫了三圈之後頭頂冒出一顆燈泡然後大喊:「我知道了!『其實我只要知道我想要什麼樣的團隊,並且朝這個方向去面試就好了』」。

於是我開始思考並且得出了幾個找人的方向:

  1. 以能力為主,個性態度什麼的普普就好了,只要不要寫 code 寫到一半會站起來大叫都還可以接受。
  2. 以個性態度為主,能力只要不要到完全不懂,並且願意努力學習,也可以配合公司工作就好。
  3. 能力好態度佳,什麼都好。
  4. 長得漂亮的女生。

第四點是開玩笑的不要當真。

然後找的人也會影響團隊的樣子,我個人分類的話大概有以下幾種團隊樣貌:

1.【競爭類型的】:個人績效至上,用績效督促每個人成長。

  • 優點:每個人會對自己做的東西很要求,
  • 缺點:不會亂寫 code,缺點是團隊合作意識可能沒這麼好,因為我如果幫助你可能會導致我績效下降,而你績效上升了。

這種類型的我覺得就是以能力為主,反正大家感情也不會說到太好,少一點勾心鬥角就很好了。

2.【團隊合作型的】:不以個人績效為主,大家互相幫忙才是最好的。

  • 優點:大家感情會很好,互相幫忙,氣氛也比較歡樂。
  • 缺點:對自己的程式碼要求會比較低,覺得會有人幫自己擦屁股,個人成長會比較慢,我要花很多時間擦屁股。

這個找人的方向就是以個性態度為主,要找那種好相處的,年紀也是考量之一,大家的年紀最好不要差太多(10歲以上),而且至少有一個女生,女生我覺得是團隊重要的潤滑劑(我是用很嚴肅的態度講的喔!)。

總而言之,考量種種因素之後,我還是希望有一個氣氛不錯的團隊,大家感情都不錯可以互相幫忙這樣,只要有基礎,其他的進來再磨練,因此我選擇了第二種

事實上這個方向也比較好成立,因為要在新創公司找到那種有衝勁、以團體為重的,要馬是新鮮人、不然就是剛轉職的新手工程師,而且現在剛轉職要當前端工程師的人,不是我要說,真的是好多啊!!選擇多自然就比較好找了。

看履歷

既然要找人就免不了要看履歷表了,自從自己開始看履歷以後,才真正能體會到以前老師或是哪個公務機關輔導就業的人員一直說的:「履歷一定要把重點放前面,或是用粗體字不同顏色的字」。

為什麼這麼說呢?一開始看履歷的時候覺得新鮮,每一句都會好好看完,但是看到後面(尤其是我在忙的時候),打開信箱有幾十封履歷,根本沒時間全部看完,更別說很多開頭都是:「我家有誰有誰有誰...」。

說真的有的寫了一大篇又沒分段的,看也只有看下面的經歷跟作品而已,然後沒作品的就幾乎都沒看了,因為面試到現在,那些技能寫一大堆的很多也不是真的懂,只要有摸個兩三下就寫上去了,也不太準,看作品或是經歷還比較有參考價值。

不過以上只是我個人的心得,可能其他人不是這樣,所以大家可以參考參考就好了。

基本上以這個方面去找人,也算是有一個不大不小的團隊了,中間過程就不贅述,基本上現在團隊人數不加我是:8個人。

學習方面

既然找的人能力方面都是以有基礎就好,自然就需要訓練了,這裡說說我觀察下來的一些結果。

以我個人方面的話,我是準備滿多新人文件的,進來就是先把文件都看過,文件包括了:「如何建構環境、Git 規範、前端規範、Vue 規範(我們寫 Vue)之類的等等」,還在持續新增中。然後有問題也都可以問我,我也會花滿多時間去教的(如果我會的話XD),我個人認為我是花滿多時間在教人的。

但是,我本來以為只要我盡力教大家能力就會上來,後來我發現很多事情不是我想像的這麼簡單。

除了我覺得我自己實在太累,我還發現有以下幾個我沒有考慮到的點:

  1. 很多人教了之後,他下次換個功能就不會了。
  2. 有人可以教的時候,就會產生依賴,覺得有問題就可以問,自己在開發功能的時候一開始都沒規劃好,遇到事情再問就好。
  3. 寫 code 參考別人的,我覺得很正常,但很多人真的就只是複製過來貼上,沒有思考過,下次輪到自己重頭寫的時候就不知道怎麼開始了。
  4. 團隊合作氣氛雖然好,但對自己寫的東西責任感很低,感覺寫錯了有別人可以擦屁股。

後來我得出了一個結論,最能使人成長的不是別的,就是「壓力」。

這個壓力指的就是:「我如果沒做好這個的話,會怎樣怎樣...」,或者是:「這個功能我應該要多久以內完成,超過的話我會覺得自己能力不夠」。

如果不給自己一點壓力或目標,盲目地在寫程式的話,我個人觀察進步的幅度總是不太理想。

不過我覺得有的人應該是知道這一點,只是沒去執行,就像我們都知道想哭的時候只要倒立眼淚就不會流下來,但想哭的時候也不會真的去倒立(我是沒看過,如果有人認識做過這件事的人的話麻煩介紹給我認識,想當朋友)。

而我個人在管理上也沒做好這點,我覺得我比較心軟一點,給的壓力比較小,這個我自己也還在鞭策自己成長中。

多人開發方面

以前端來說.我自己經歷過幾種開發團隊的規模:1人、2人、3人到現在8人。

我個人覺得團隊開發最重要的一點就是 Coding Style 了,如果一個團隊沒有做好規範的話那真的是很可怕的事情,這也是為什麼我要寫一堆文件的原因,我個人是就算一個人開發也會把該加的規範加上去,參與多人開發的時候也比較習慣。

我覺得分工也是一大難題,以前在開發通常都是頁面為主,比如說:「你做首頁,我做登入」,但有時候會遇到一個問題就是這次開發的就只有四頁,要怎麼讓八個人去分?

所以後來就把維度縮小,很多功能以組件去分,之後再組起來,也比較不容易有衝突。

一個人開發的時候,只要自己負擔得了,想用什麼技術就用什麼技術,但在多人團隊就不一樣了,不是你想寫什麼就可以寫什麼的。

我個人的準則是想導入的人要學會一定程度以上的知識,而且要說服大家為什麼要用這個,然後教導大家至少能夠基礎實作,不要拖到專案進度就可以。

這裡很重點是說要會一定程度的原因是,你不能說:「我這次新專案想用 Xstate,但我不太會,想在新專案練習看看」,如果連你自己都不太會了,為什麼大家要配合你,如果因為用了這個新技術然後進度開天窗怎麼辦?

所以正常想用一些新技術應該是在自己的 side project 練習完之後才提出來。

啊忘了說,後來得力同事回南部,主管剩下我一個人了,真的是滿累的XD

以上大概就是我當主管的一些小小心得了。

總結

雖然這幾年瘋狂在寫程式很累,但我覺得滿值得的,因為我從一個害怕會不會找不到工作的人,變成一個可以安穩過生活的人,也不會再讓家人擔心了,而且寫程式也滿有趣的啦!

只是我覺得非本科系必須多花時間去補足基本的知識,比如說我可能會花一些時間去理解像是:OSI 模型、什麼是 TCP/UDP、揮發記憶體跟非揮發記憶體之類的等等,但其實年紀漸漸大了有變得比較愛讀書,所以去學習這些對我也不算是什麼困擾就是了(當工程師之後身體年齡來到50歲)。

總之我覺得轉職工程師在現在是真的滿不錯的,但我覺得想轉職的人不要把這個行業想得太簡單,好像覺得反正我只要上了課就能找到高薪工作,老實說這個行業其實滿難的,以我現在在做的前端,技術更新實在是太快了,如果不時時刻刻跟上的話很快就被淘汰了,雖然我打文章感覺輕描淡寫的,但我也是經歷過無數個痛苦的夜晚 QQ。

以上只是一個菜鳥小主管的心得,如果有人有更好的意見或想法也歡迎提供給我跟我討論喔!!

啊忘了說最重要的,體重一定要注意一下,不要因為壓力大就一直吃。

60 Kg→ 75Kg的男人上。

--

--