你能學會多少技術？

在〈You Know Nothing About Code〉（http://goo.gl/uRIHD8）這篇文章之中，Alex Parker說到：「習慣它吧！別想要無所不通！」然而，程式人總是得隨時隨時精進自我，這似乎是種矛盾，只是在現今的技術洪流中，我們又能跟得上多少技術呢？

這麼多感應器，怎麼學得完？

由於在軟體領域的時間浸淫的時間比較多，對一門技術完全從無到有的感覺，相對來說已經沒有那麼強烈。

學習新的程式語言時，即使語言中標榜著多麼與眾不同的新語法，然而憑藉著已熟知的程式語言，要再獲取一門新語言總是沒麼難的感覺，學習一個新程式庫，新的框架、新的工具等，基本上不會遇到什麼大問題，憑藉著過去的經驗，多半都得以解決問題，是否學習一門技術，除了工作需求之外，多半是基於興趣罷了。

不過，最近一陣子接觸微控制器以來，發現心裡總是時不時地問自己：「這麼多感應器，怎麼學得完？」或許是在這領域荒廢了十幾年，在這個領域的基礎幾近於歸零，各方面知識完全從無到有的感覺就被突顯了出來，而且，某些程度上，各種感應器模組，可以比擬為軟體領域的程式庫，而微控制器大概就是框架了，我開始明白，為何在軟體領域總是會有人問我：「這麼多的技術，接下來我該學什麼？」

相對其他領域來說，軟體領域的技術進展可說是異常的快，想要成為程式設計者的條件之一，就是能不斷學習新技術，除了工作上會用到的技術之外，有餘力的情況下，也得學習工作上暫時用不到的技術，到PTT的Soft_Job搜尋標題中有「下班」的文章，就會發現許多人在下班是否還要學習相關技術上糾結，這多半也反應出能不斷學習新技術，對身處軟體領域來說，絕對是必要的能力。

這麼多的技術，怎麼學得完？這麼多感應器，怎麼學得完？我很明白，漫無目的地學習，只會迷失方向，最後只會學了一堆，卻不知道怎麼整合與應用，因而最近我在工作之餘，開始了一些小的Side Project，先是試著仿做Plotclock（http://goo.gl/fA4gR5），接著試著自己設計六足機器昆蟲，然後遇上些問題，接著想辦法克服它們，無論是用上新學到的東西，或者是需要一些稍稍超出我目前程度，但又能進一步掌控的知識。

學著將廣度化為深度

在《The Pragmatic Programmer》書中第一章，對程式人在知識投資組合（Knowledge portfolio）上給的第一個建議是：「每年至少學習一門新語言」，其理由是不同的語言會以不同的方式解決問題，因而可以學到不同的解決方法，藉此保有想法上的活力，避免一成不變。

就我學習各種語言的經驗來說，確實是如此。從JavaScript中，可以學得基於一級函式與基於原型的設計；從Python中，瞭解到保持簡潔與一致性的重要與方法；從Ruby中，習得meta-programming的作法與彈性；從Haskell中，學到了純函數式中隔離副作用的好處與思路。

不過，當想要解決問題時，在可以的情況下，我還是會選擇使用Java來解決問題，而曾經在其他語言中學到的想法，將會成為使用Java過程當中可能運用的元素。

即使是學習各語言背後生態圈中各自衍生的技術或工具，也是如此。像是Rails快速開發框架的概念，Node.js的非同步設計等，學習的同時我都會思索，在Java的領域中，有沒有對應的產品或者設計方式，有沒有辦法將各語言生態系中獲得的廣度，深化到Java之中。

另一方面，我並不是對各種技術有興趣，而是對這些技術背後要解決的問題有興趣，以及它們是如何被解決；知道這些之後，當在Java中面對類似的問題，若情況適當，我就可以用最熟悉的語言或工具，但採用另一個領域中更好的設計方式來解決。

有趣的是，語言之間總是會互相學習，而很快地，某個技術領域解決問題的方式，會在另一個領域實現，無論那是透過語言本身的新特性，或者是程式庫、框架等方式，在此同時，被深入到Java之中的知識，就得以獲得應用。

辨識問題，並解決問題

這年頭，想要成為一名程式設計師，要懂的東西還真的是不少，實際上除了技術之外，還得懂演算法、資料結構等理論基礎。

前些日子就發生了Homebrew作者Max Howell 在面試Google時，因為沒能在白板上反轉二元樹，而被Google拒絕的事（https://goo.gl/s8uy3E），儘管各方對這件面試事件有各種不同的角度與看法，然而也表示了演算法、資料結構這類理論基礎，對身為程式設計師來說，仍是件值得被重視的事，對了，也有不少人建議，寫程式最好要懂數學！

如果沒有具體待解決的問題存在，討論寫程式要不要懂演算法、資料結構甚至數學這個問題，基本上就不會有交集存在，總有人會聲稱寫程式至目前為止，從沒有（直接）用過演算法、資料結構或數學。

其實，如果他過往遇到的問題不是演算法、資料結構或數學要解決的對象，這種說法並沒有錯，如果他今天遇上的問題是要往圓錐水槽注水，且必須用程式來控制水面的上升速率，就很難不用上數學。

有一定經驗的程式設計師，遇上問題，往往能第一時間就知道根源在哪，有時第一時間雖不知道根源何在，基於過去的經驗來推敲，也能找出並解決問題。這種「Debug的直覺」，不少人都有過類似經驗，這其實是因為過去面對過足夠多的問題，並累積了多個解決問題的思路與方向，方能有這類Debug的直覺。

無論是數學、資料結構、演算法或者各種技術，不過就是解決問題時可運用的工具，因為，手邊有的工具越多，解決問題的方法就越多。

學習更多技術，是為了辨識出有哪些問題並解決問題，學習演算法、資料結構、數學等理論基礎，也是要辨識有哪些問題並可以用這類理論來解決。

因此，辨識問題是一個很重要的能力，不少人應該都有這類經驗，明明在你眼中顯而易見的問題，為何有些程式新手就是看不出問題，學的技術或理論越多，就要能辨識更多的問題，也才越能基於廣博知識來解決問題。

動手做並面對失敗

這陣子接觸微控制器有不少感想，其中之一是，學習硬體比學習軟體，在金錢成本上比較顯而易見。軟體上要嘗試程式庫、框架、工具，網路上有取之不盡的資源，而且通常（表面上）免費，學習微控制器要玩個感應器或電路模組，總是得花錢購買，在銜接各模組時一個不小心，還會「碰」個一聲，看著電路模組冒出一縷輕煙。接觸微控制器時，學會面對這類的失敗，是個必要的過程。

實驗需要成本，相對來說，軟體上一開始面對失敗時的金錢成本比較低，因此別浪費這種機會了。在學習各種技術的同時，你應該儘可能地動手做各種實驗，實驗若失敗了其實應該高興，每面對一次失敗，就多一次經驗，每解決一次失敗，就多一份能力。在程式設計這領域，特別強調Get your hand dirty，就是這樣的道理。

在Maker領域中〈想靠3D列印創業嗎？〉（http://goo.gl/Yh3v7I）中，有句話寫道：「列印想法，而不是列印產品」，這讓我在學習各種感應器使用或電路模組原理的過程中，能時時承認「學不了所有的東西」，這樣我就能知道該學習的是辨識問題與面對失敗，而不是學習所有的技術，無論那是在硬體上的技術，或者是軟體！