內容大綱

一、這篇文章想傳達的
二、開場問題
三、理解程式學習的盲點與關鍵
四、該怎麼解決？談談現在常見的學習方式
五、結論

HackMD 系列目錄
HackMD 好讀連結

一、這篇文章想傳達的

不斷的學習技術和工具，對於許多在職與轉職的工程師而言，是一個共同煩惱，希望能透過這篇文章，傳達我從工程師和教學現場，為什麼大部分的學習問題，來自及對於學習程式的盲點和狀態，產生了學不完的學習焦慮。

這篇文章不是讓所有人都能成為工程師，也不是教你如何不用辛苦成為優秀的工程師。

文章的觀點如果和你的觀點不同、沒涵蓋到的觀點、有其他想法要補充，也都歡迎提出來。

二、開場問題

在進入主題之前，希望讀者先將以下的問題記住，然後在閱讀完所有的內容後，再問自己，這些問題是否已經有了答案。

問題一：學習效率差
為何總覺得自己學習程式的效率不佳，感覺始終無法看到終點呢？

問題二：永遠覺得學的不夠
即使自己上了轉職軟體工程師的課程，瀏覽了眾多學習資源，完成了大量的練習，仍覺得自己學的不足？

問題三：需要不斷學習新事物的焦慮
雖然第一年成功轉職成為軟體工程師，但是工作了一段時間後發現，需要一直不斷的學習新的技術、工具，這樣的學習焦慮，導致自己走不下去，我該怎麼調整？

問題四：無法面對未曾學習或遇過的問題
認為自己因為學的不夠多，導致非常害怕，在工作時面對沒有遇過的問題，我該怎麼去彌補和調整自己？

三、理解程式學習的盲點與關鍵

之所以大多數人被上面這些問題影響，背後的關鍵是：
我們從小到大教育體制和觀念，讓我們的學習認知和狀態，處於「被動」的狀態。

什麼是被動的狀態，舉例來說？

1. 老師給我什麼，教材給我什麼，我就接收什麼，我在學習的當下，沒辦法「體會」這些內容的重要性。
2. 等到反覆熟悉、足夠深入所有的觀念、程式語法、工具用法之後，才有勇氣去考試、面對問題、開始做作品，就像學生準備考試，目標是拿到滿分。

為什麼處於被動學習的狀態，導致學習效率這麼差？

(一) 抓不到學習的主次方向和順序：

東學一塊，西學一塊，東與西沒有關聯，學到後面忘記前面．最後無法拼在一起，解決綜合性的問題。

例子1：
想像一位剛接觸 Java 的新手，在學習 Hello World 的程式時，就花費大量時間在研究 static 和 class 的觀念。

對於剛接觸 Java 的新手，當下真正的學習目標是，理解撰寫程式時，要先學會怎麼編譯和執行一隻程式。當 Hello World 程式能順利編譯和執行之後，該怎麼將資料輸入到程式，程式處理後的資料要怎麼輸出程式。

所以說，那個時機點不知道 static 和 class，根本就不影響學習，就算超前部署學習，只會增加學習焦慮。

(二) 沒有一個明確的目標導向

誤以為先熟悉所有的東西，就會應用，最終花費了比別人更多的時間，換來了更多學習焦慮。

例子2：
想像一位剛接觸 Vue 的新手，他花了非常多時間,一個一個把 ref, reactive, readonly, computed, watch, watchEffect, ref 的觀念弄到**非常熟悉**以後，才開始練習寫作品。

結果開始練習作品的時候，發現換頁的功能，還需要學會 vue-router, 所以他又慢慢的把 vue-router 的所有東西都啃完之後，才也信心完成換頁的功能。

這例子也是多數人會認為學習框架相當吃力的狀況，上面提的東西每個都很重要，但是，填鴨式的全部熟悉之後才開始練習，要花多少時間？真正會用的又有多少？

這邊要強調，雖然深入的熟悉瞭解，才有辦法活用，但是在沒有問題引導、功能實作等時機因素，很多時候過早深入學習，對大腦來說不只沒有感覺，容易遺忘，而且還會一直煩惱，到底還有多少要學。

常見的結果就是：一旦套件或框架經過大改版，心裡就會非常的害怕與抗拒接觸，因為當初投入了這麼多時間學習，結果又要重新深入學習。

(三) 缺乏語言之外的自學能力訓練

有的課程不太會設計問題或情境，去引導學生，怎麼除錯、查文件，大多的課程設計，是希望學生順利的手把手跟著完成程式專案。因為這樣設計，會大幅增加學生的挫折感，以及學生在課程的體驗，對課程銷售本身並不是一件好事。

另外一種狀況，就是那個人本身的特質和個性，比較耐不住處理程式問題的枯燥，也就是不適合寫程式。

例子3：
養成了手把手把所有的程式、範例照著做，就會有結果的習慣，在參與課程的過程中，許多問題和練習，只要詢問老師或助教，就有答案，認為只要是我不知道的事情，或者我遇到的問題，老師和助教有義務幫我到底。

成功轉職之後，這個習慣帶到了職場，把同事當老師或助教依賴，狂問問題，請同事處理 Bug 增加同事的工作負擔，被同事責難伸手牌，結果之後又因為害怕問同事，該問的事情沒問搞出大事。

這個問題的根源，就是缺少「動手嘗試」和「查資料」的能力，也是我觀察許多線上課程、實體課程比較難以訓練的部分。

(四) 缺乏足夠而且有效的練習

大多數公司考解題的目的，是為了測驗基本的程式語法、資料結構、演算法和思考邏輯等能力，但是有很多工作經常處理的問題，不是在解題平台上能練習到的。例如：第三方套件的使用、跟電腦環境有關的開發問題、工具的使用。

還有常見的一種人，就是光用眼睛看，完全沒動手和思考的人，或者完全照做，沒有嘗試加入自己的練習和變化．這類的人在面試時，主考官只要出一個情境修改，就很容易出局。

例子4：
一位有心轉職前端工程師的初學者，聽說面試會考程式解題，在一開始接觸時，直接投入了大量的時間在 leet code, HackerRank 等解題平台練習 JavaScript，結果應徵時，沒什麼代表性的作品，可以證明解題之外的開發能力，例如：瀏覽器的開發工具、DOM 的操作、串接 WebAPI、怎麼運用 Cookie 和 Storage。

解題能力固然重要，平常有空或者要準備面試前，都可以適當練習，但是解題之外的作品練習也相當重要

有一種例外：產業或技術性質比較封閉(韌體、Cobol、特定 ERP 語言)，很多東西是進去之後再學，這時著重在基礎和解題的效益就會比較大。

四、該怎麼解決？談談現在常見的學習模式

要解決被動學習的根源，其實就是讓踏入工程師的人，要有一個認知：「很多東西是需要的時候才學習」，轉換成主動學習的狀態。

這邊要強調，對於初學者來說，「系統的學習仍然非常重要」。但是，系統的學習和訓練，要能足以支那些初階工程師，脫離課程後，透過他人指點方向，或者自己面對未知的問題和能力，而不是指望學完課程所有的內容，工作就能一路順遂，不用學習新的技術和工具，除非是比較封閉冷猛的技術，或者是比較重 Domain Know how 的領域。

一旦調適了學習的認知和狀態，你會發現前面的開場問題，根本就不是問題，這也是長期在職場的軟體工程師，真正的學習認知和狀態。

接下來的問題是，該怎麼轉換成主動的學習狀態？就要往下探討，目前常見的兩種學習模式：

(一) 專案式學習 (宏觀角度)

這樣的學習模式，主要是為了從整體的角度，透過功能實作，認識並掌握零散語法的整體用法。

最常遇到的問題是什麼？大多數人跟著課程手把手做完之後，就認為學完了，也不太去深入瞭解課程沒提到的觀念和語法，結果就是不知道也不太敢去修改程式的專案，面試時直接被人認出來是課程的作品。

(二) 實驗式學習 (微觀角度)

這樣的學習模式，通常會把每個語法或觀念，拆開一個一個講解並實作，而這樣的模式，也是工作學習時，在需要深入瞭解某個語法或觀念時，會採用的做法。

簡單來說，這種方式正好可以解決專案式學習，不知道怎麼修改程式的問題，但如果主要仰賴這個方式學習，結果會和專案式學習相反：「熟悉每個觀念和語法，但是不知道怎麼拚起來運用。」

所以最好的方式是什麼？適當的混用兩種學習模式：

1. 透過專案式的學習，瞭解觀念語法的「方向」和「整體」。
2. 當你有了問題和情境等動機引導，深入瞭解每個觀念語法。

套用在工作學習上：

1. 藉由工作完成的功能開發，或者面對到的問題，整理出可能的方向
2. 針對這些整理的方向，深入瞭解觀念或語法。

這也是我自己和觀察其他的資深同事採用的方式。
不管是付錢上課，還是善用免費的線上資源，都是可以適用的，具體怎麼做，之後有時間再撰寫另一個篇幅介紹。

五、結論

程式技術的變化相當的迅速，不確定性也非常多，被動學習的狀態，除了容易給自己不必要的學習焦慮，也容易在錯誤的時間點，投入過多的精力深入學習，導致學習效率也相當的差。

工程師不是只有程式語言、第三方套件要學習，還有共同的電腦科學(或者叫計算機概論)，每個開發領域當中的開發工具要學習，實際的學習方式，以及關注的地方都不太一樣。

所以，掌握了學習的本質，最終是讓你能夠重新調適，自己的學習問題和方向，能不能成為長久生存的工程師，最終仍需要靠自己的努力，沒有人知道。

最後，拋出一個問題總結：
為什麼有一定經驗的工程師，通常學習效率都會比較好，也比較不像轉職的人容易有學習焦慮？

因為每天工作，都有許多的產品或專案開發問題需要解決，也因此，為了處理並解決問題，當下就是主動的學習狀態，如果不去解決，就只好解決人的問題或提離職。

第一篇內容到這邊結束，謝謝大家耐心的閱讀。