抱歉本想推文的，但想回的東西比較多，請容我再囉嗦一篇。
每個人適合的方式跟機運大不同，自己的經驗通常也無法適用於別人，
所以我沒有勸進，但也並非勸退，而是要推薦原 po 用"低成本"的方式幫助自己評估。
能不能轉職因人而異，但可以確定的是，至少要能夠適應這個行業在做的事情
所以會推薦先自學到一定程度，做做專案，和業內人士交流，應該心裡就會有個底了。
不是年紀大就不能轉行，而是轉的成本和風險會比較高，所以推薦比較安全的評估方式
不妨先試試習慣一下水溫，再決定要不要頭整個洗下去。
我算比較幸運，剛好本身興趣，多年持續有自學，所以三十幾轉行本身有程式基礎
並不是真正從零開始的，成功率可能高些。但事情也沒有表面上看來的順利
我年輕時學的是傳統視窗程式，HTML 4.0 (還沒 css)，JavaScript 只會做跑馬燈
最多會點 jQuery，中年轉行時主流都 web 2.0 和機器學習了，這些我根本完全沒學過
因為沒受過正規訓練，所以很多理論跟專有名詞也不懂，多半還是土法煉鋼的。
所以去讀研究所跟剛進業界的時候，其實也是過得很辛苦的，也有很多跟不上的時候。
可能在一些人眼裡可以跨領域自學滿厲害，但見識過業內真正厲害的人之後，
我完全理解自己懂的東西真的太少了，在很多領域還是一張白紙，需要從頭學。
資訊領域是沒有國界的，我們的同業不是只有身邊的同事，還包括美國、印度、中國
等世界級的頂尖人才，自信心很容易受到打擊，所以心理上的調適很重要的!
上篇有網友推文，還沒學基礎，就推薦做專案很不實際。
其實我覺得直接做專案，正是最實際的上手方法，因為你只學了"真正要用到的"
用工作剩餘的時間學東西，最難的就是時間不夠，所以得抓重點學。
學生時代可以花一個學期慢慢整本讀完，靠寫作業考試來練習。
時間不夠話比較難這樣，先找個小專案，針對要用到的部分重點式學習
然後再逐步深入理解相關知識，有時候效率上會比較好。
舉例來說，我當年開發 bbs 連線軟體的時候，其實才剛在學 C++ 而已，
也是一邊看書，到處看網站抄範例來拼湊，慢慢把想要的功能堆出來的。
當時也沒聽過 STL，更不會用 template，連繼承都用得一知半解，但還是做出來了。
因為要連網路，所以看了點 socket 程式。因為連線時候視窗會卡住，
去查才知道原來要開 background thread，所以就知道了 multi-threading。
遇到要層層掃描目錄下的檔案，一開始學習別人的範例，後來看書才知道那叫遞迴
十幾年後去補讀了研究所，重學了演算法，我才知道那個原來叫做 DFS...
因為要處理 telnet 通訊協定，想了想好像可以用個 flag 紀錄目前的狀態
然後收到指令處理完，再改變狀態，好像這樣的結構程式會比較好寫。
很多年以後，我才知道那個叫做 state machine。
這樣土法煉鋼的結果，當然就是程式寫得亂七八糟，最後很多就維護不下去了
多年後讀到 design pattern，很多看了就豁然開朗! 它解的問題，正是我踩過的坑。
這樣學到之後就不會忘記了，這樣的學習，比起考完就還給老師，反而印象更深刻。
所以你說沒基礎能不能一來就做專案？我會說可以。
比起讀完很多卻不知道要幹嘛，反而先知道要幹嘛，你就會很清楚該要讀什麼。
從錯誤經驗中學習，有時也是很有效的學習。