一直都是這樣子的，有時候根本都是硬體的問題通通怪到 FW 上面。
你那個只是設計不好，硬要凹 FW 而已，你應該沒看過程度很誇張的 HW，有沒有見過 power in 沒拉 trace、nor 跟 nand 可以當成一樣的東西來換料的？(理由更好笑：我以為 pin to pin 可以直接換)，跳線跳個十幾條讓板子會動都是小意思，板子有問題都要我們 FW 自己 debug 跟跳線搞到會動為止，當然 debug 跟 driver 還是要你做，上面的 application 還是你要寫，HW 跟沒事的人一樣，一有問題只會找 FW。
像你這樣優秀的人才是應該不會碰到我上述這種鳥事。



我也是出了校門就沒碰過示波器啊，直到幾年前回來搞 embedded 才開始摸，這東西沒啥技巧啦，常用就會了，反正大部份都是 auto 按按，最多設設 trigger 而已~
Z80 一點都不古董，現在還一大堆人在用 (8051、Keil C)，基本觀念都是一樣的。
這東西要真的熟還是要自己碰，當年開 8051 的課，老師自己都不太會，教科書上的程式根本都不能動，最後是我自己寫一個真的會動的版本給全班同學 copy。

小弟再提一個看法，如果想用苦幹蠻幹的方式往上爬，必須先看主事者的性格，這種方法，並不是在每一家公司都有效；更有可能的情況是，被上面的人認為你只是一個苦工，而不是人才。

就管理上，如果員工常常必須加班才能完成工作，絕對是必須要檢討的，通常這有兩種狀況，１．分配的工作不合理，超過該職位應負荷的工作量。２．該員工的能力不足，無法擔任這個職位。無論是哪種狀況，都應該做出相應的處置，才不會影響工作的進行。

就我看過的實例，很多時候是主管沒有魄力，能力不足的沒被換掉，造成其它人必須做更多的工作來彌補。如果遇到這樣的主管，建議還是換個環境，良禽擇木而棲、良臣擇主而侍。

個人所在的公司主管,訂了一套績效評估標準.
在這套標準中,唯一能夠被明確量化的,就是速度.

由於台灣公司的薪資當然都是秘密,
主管可能會告訴你,你的薪資是高於平均的,所以你的產能必須高於平均,
(在這套績效評估標準下,也就是速度)
但是真相究竟如何,你不可能知道.

為了高於平均,於是你可能必須每天加班,假日加班,
辦公室做不完的,回家繼續做(不論你是用什麼方法).

雖然不知道主管是怎麼跟其他人說的,但是很明確的是:
大家都是辦公室做不完的,下班回家後繼續做(不論你是用什麼方法).

公司雖然有加班單可以填, 但別想申請,因為會用各種理由/說法,
要求你自己撤銷申請.

所以,你即使也是平日/假日都加班工作,
並且提早完成工作,換來的也只是更多的工作,而非喘息.
而且,你並不會因此而獲得更高的加薪,
因為主管已經告訴你了,你的薪資高於平均.

站在主管的角度, 也許這個方法,就是這個主管在公司的維持生存之道:
帳面上,員工正常上下班,績效上,持續成長.

真有需要加班, 主管才會提出, 你自己一個人能力再好再強, 也是需要團隊合作, 上下左右有人

出了問題, 很難一人置身事外. 我的部門平日是不加班的, 但真要加班時, 做通宵也會配合.

很多時候大家心中都有很多理想化的遠景, 但基於結果, 基於事實, 現在就還不是那個樣, 該

處理的急事要解決, 看到組織的問題也要克服, 治標治本兩者要兼具, 不是擇一. 這就是我跟我

部門同仁溝通的觀念. 這件鳥事情根本的解法是要改A部門的流程, 嗯~很棒很好. 但這理想

還沒出現, 客戶明天下午三點前要的貨200套現在有問題, 那該怎麼做? 先捲起袖子下去做事吧~

等貨交了驗收完, 你要改組織改流程再來談. 這就是偶爾需要跟現實妥協的地方.