我想分享的是：寫韌體，就不需要懂軟體嗎？
如果問多數人，韌體工程師的工作。我籠統點說，絕大多數人會認為："看spec操作IO的工作"、"寫MCU"、"寫一台機器的軟體，但機器看起來不像電腦"，就是韌體工程師的工作，所以公司與個人也是以軔體工程師去求才或求職。所以韌體工程師的確是此類工作的代名詞。這種工作有很多的竅門與專業知識，比如說：使用示波器、邏輯分析、電表、甚至頻譜分析儀來協助工作，也要看懂電路圖，以及電子電路的常識。但是這僅止於driver的部份，也就是你的產品想要賣錢，不是只要把driver做好就可以，一定還要有軟體才能完成一個產品。
天不從人願，哪有韌體工程師只要寫driver這個好康的事？當然要繼續往上開發出功能才行阿！不然你都會C語言了，老闆當然覺得你應該可以勝任。這時你應該知道如果推辭或擺爛，那你就被打入永遠寫driver的冷宮，老闆就會再找軟體的人來取代你，或是跟你合作，你就賺不到更多錢。我奉勸此類的朋友，持續的向上學習才是王道。所以這文章也是寫給努力向上的人看的。OK，既然要合作或是學習，韌體工程師就不能置身事外。韌體工程師最終還是要關心軟體領域會發生的問題，縱使你寫的軟體是放在flash或eeprom，而變成自詡為韌體工程師，但你卻因此不繼續探索軟體領域的解決方法，這想必是緣木求魚。
韌體要coding，軟體要coding。只要是一群人合作一起coding，不管他是coding來控制硬體，還是coding來UI的，還是coding來網頁的，甚至是用嘴巴coding的，都一定會遭遇到一些問題：
- 版本管理
- debug，而且具有非常不平衡的性質。就是可能改錯1個字，或是一行，都有可能造成嚴重錯誤。
- 不可預測性，常常計畫趕不上老闆一句話，韌體有時也是會牽連修改。只要修改，就可能有bug。
這些問題，如果不知道方法處理的team，就是以吵架收場。不知道該怎麼去處理，一而再再而三的prj延宕，讓老闆失去耐心後，你不解決問題，就是等著被老闆解決。
這些問題只是軟體開發的冰山一角，韌體開發的coding，還可以再寫一堆落落長的注意事項...。看，不可否認，即使你原本是韌體工程師，可能只寫driver或MCU的程式，最後還是會遇到這些問題。所以我只講版本管理就好，就像是使用svn、git這類工具，即使你是寫8051或寫driver或者是寫 " 放在rom裡的軟體 " ，你都必須管理版本。當然軟體的領域不只有版本管理這個項目，Bug tracking system、Jenkins CI、Agile、UML...這些也只是團隊合作上的工具，在整個軟體系統建構的過程中，還有好多好多東西要學的。先前分享的書裡面就有提到很多像是coding、design pattern、testing..etc.：
無論你是用什麼程式語言，無論你寫完的程式是放在哪裡跑，這些知識都有助於你解決問題。韌體這名詞對我來說，可說是寫完的軟體放到比較不容易修改的ROM裡面的Release方式罷了。所以我認為，絕不要因為自稱為韌體工程師就不去使用自認為"純軟體"在用的工具或知識，或者認為自己不吃軟體工程這一套。只要是對解決問題有幫助的知識，就應該持續向上學習與虛心的跟別人合作，才是工程師的生存之道。
無論你是用什麼程式語言，無論你寫完的程式是放在哪裡跑，這些知識都有助於你解決問題。韌體這名詞對我來說，可說是寫完的軟體放到比較不容易修改的ROM裡面的Release方式罷了。所以我認為，絕不要因為自稱為韌體工程師就不去使用自認為"純軟體"在用的工具或知識，或者認為自己不吃軟體工程這一套。只要是對解決問題有幫助的知識，就應該持續向上學習與虛心的跟別人合作，才是工程師的生存之道。
我結論是：原本寫韌體，想要更上層樓，就要朝向軟體發展。因為簡單來說沒有韌体工程這門學科。
