嵌入式行業入行3年的一點小感想

• 2021 年 6 月 24 日
• 筆記
• summary

背景

距離18年畢業典禮那天，到今天剛好過去了3個年頭。重新去回顧這幾年來工作上經歷，我覺得還是有必要小小地記錄一下；畢竟，沒有記錄的日子，等於未曾發生。

下述的公司都以縮寫代替。

摸爬滾打之路

初入職場

我還記得一開始出來工作的時候，編程能力只停留於電腦2級C語言及格線的水平線左右，外加只會一點點Linux命令行操作；經過自己的爭取和面試官的包容，我來到了GSK。

在培養人才的角度來看，GSK是一家很好的公司，現在想想，和部門內的同事相處的日子依舊很融洽。我們部門中的每一位同事，都在嵌入式行業中各個領域有所建樹；我不止一次地和別人提到過他們在下面行業各自的成就：

• 工業匯流排：Can、modbus、ethercat ；以及內部實現的可拓展現場匯流排
• ARM平台指令與彙編、故障排查
• 作業系統以及組件移植
• 產線工具以及新技術開發
• 外設通訊與協議…

以及，部門老大在知識管理以及技術管理方面的教導以及對目標的毅力我是很欽佩的。

可以說，正是有了他們，我對行業的了解才會比較深刻。

那個時候，離開學校沒多久的我，對於嵌入式行業的還停留在老舊的理論水平；但在部門的培養下（主要是因為我的直屬領導），我對嵌入式行業、尤其是工控方面的開始有了自己的理解。以至於現在的我，對於產品中必要的實時性、可靠性還是很敏感。

我在工作中的大部分時候是幫其他部門開發一些底層的組件，確認他們在驅動程式的使用上是否存在問題。

因為初出茅廬，我在遇到不懂的問題，經過思考以後都會去問同事Alex。

Alex每次聽到我的疑問以後，總是會用手摸下巴，低頭思考一會，並問我，「你的需求是什麼，你想實現什麼？」

有經驗的工程師不會專門去滿足你的需求，他會先確認你要實現的結果，然後回饋給你一個更好的方案；或者評估過認為可行性有問題而直接拒絕你。

我也見過他當面拒絕一位心高氣傲的其他部門老工程師的需求；我很佩服他知道什麼必須做，什麼不應該做。

待會我們說一下「溝通」的話題。

出於獨立的態度，當時的我也不太喜歡去求助別人。（但在當時，其實還是應該多多學習，積極提問；我有點後悔當時沒有好好珍惜當時的機會；但這是後話了）

後來，我擔心成長速度太慢而離開了這家公司；但在離開的時候，我也勉勉強強能夠搞點Linux驅動的東西了；但也只是皮毛。想著成長快一點，我又跑到了一家小公司。離開的時候，領導聽說我要從黃埔跑去荔灣，笑著問我是不是跨度有點大。

在小公司的日子

那個時候，算上實習生，在我們技術經理還沒離職之前，我們技術部共有6個人。我負責驅動，還有其他同事負責web以及基於海思SDK的應用程式開發。

相比大公司對人才成長的包容，小公司GK對於研髮結果的渴望來得更為強烈，老闆巴不得你每天坐在工位上，從早干到晚。

後面也會提到關於我對加班的看法。

因為不懂技術的人不知道如何量化研發人員的貢獻，所以只會用所謂的工作時間來衡量你的產出。說實話，我一直不喜歡這一點，這屬於一種管理無能。我贊同《極客與團隊》書中的這個觀點：技術Leader應該要有自己的底氣，來cover自己的團隊在一個更加穩定的環境下安心地工作以及成長。

因為產品不夠穩定就發布了，以至於發生了很多從現在看起來「算是有趣」的事情：

• 銷售要求第二天早上就要發貨，可是到了晚上10點的時候，我還在緊急排查一個產品問題；當時心裡真的很著急；結果我的領導告訴我，「遇到實在是搞不定的問題，你先休息一下，可能待會就有思路。」，第二天早上，我一大早來到公司，排查到是因為文件系統中庫的軟鏈接丟了，鏈上以後就按時發貨了。

• 有幾次我們需要去客戶現場出差；和實施工程師一起在使用自己部門開發的產品的時候，我才發現：搞產品不能依賴於研發人員的思維，要從用戶的角度來看待你寫的產品——因為他們並不關心你的內部實現有多trickly，你能滿足他們的需求，而且穩定可用就算是滿分了。也是從那個時候起，我知道一線的同事其實是很不容易的，能積極配合的工作一定要積極配合，同是打工人，沒必要相互揣著一副自以為是的架子。

• 我還記得和我們領導因為產品在推流的時候出問題，便一起跑去浙江現場去看。那個時候兩個人住在酒店裡，人生地不熟，我小聲「嘖」了一下當時在電梯里吸煙的兩個痞子。事後我的領導告誡我，不要去惹這些人，因為你如果得罪了那些人，對你來說很不值得，你不會去犯罪，但他們不一定也這麼想；而且，他們的時間不如你的時間值錢。

受限於產品線的平台，很快在驅動方面我就沒有什麼發展的空間了，而且領導想讓我往Windows-SDK應用靠攏；因此我權衡了一下，選擇了離開。那個時候我在迷茫要不要繼續搞底層驅動，猶豫過一兩次往應用開發方向去靠攏。

所以，當時的我在空閑的期間鞏固了自己的Qt以及c/c++的語法與設計模式；雖然最後沒有往應用方向繼續發展，所幸我在有必要的時候開發一些小工具來改進我的工作效率。

我所學習的應用層上的東西，在在後面分析Android源碼的時候，尤其是看Framework的東西比較受用。

女朋友也很喜歡我寫的定期提醒她起來活動一下身體的小工具。

技術儲備的魅力在於，你很久以前學了但是以為用不上的東西，突然在某一天變得很有用。其實都是自然而然的事情，還是要多多學習，觸類旁通。

最後，我離開之前，向行政部的同事回饋過公司存在的問題，也聽到她對此表示的無奈。

她的原話我記不清楚了，但是大意是：「公司的價值觀由公司最具有影響力的人來決定；在小公司，我們都知道那個人就是付你工錢的老闆。」

重回大公司

體驗過小公司以後，我還是希望往大公司靠攏；後面我去了一家大公司BL。

在我入職的第二天，部門內部會議上，當時還沒被開除的領導告訴我們，每人每天必須呆到晚上8點以後才能走。領導安慰我們說，「這是奮鬥者的天堂」。因為這個”強制加班的”新制度，有幾位工作效率很高的人陸陸續續離職了。

我曾嘗試去符合公司的這個新「規定」，一開始工作效率隨著工作時間提高了，但隨著休息和總結的時間越來越少，發現工作效率變得越來越低，最後人也有點急躁。

我還記得當時其中的一位同事，謝工，雖然帶著口罩，我已經記不起他的臉，但他的工作方式讓我印象深刻。他說話語速很快，但是當你和他溝通的時候，他也會像Alex一樣，先確保他的理解和你的理解是一致的：「你想做的是xxx對嗎？換個說法，是不是xxx’ 對嗎？OK，我清楚了。」

我在這家公司工作的一個感想就是，之前學到的很多理念和演算法以及驅動開發，終於可以再次派上用場了。而且，之前在GSK中接觸的ZYNQ 7000平台，我也終於大概摸了個遍，也算是彌補了最初的一個遺憾——如何完整地搭建一個嵌入式Linux系統，我已經很了解了，但我知道，這也只是補了當時在GSK沒有完成的作業而已罷了。

在編寫程式碼的時候，出於可靠性驗證；我刻意區分了根據功能塊進行分層解耦，並配合對應的test-unit，在開發自測並解決了很多BUG；而且，測試人員壓測中報告的BUG，也很快在unit中定位了——這就是TDD（測試驅動開發）所帶來的好處；沒有對比就沒有傷害，別人在改BUG的時候，我已經可以去做別的事情了。

後來，領導被離職了以後；出於對部門的擔憂，我趁機也走了。

在這個時候，我自己寫的驅動已經有點內核程式碼的味道了，雖然還是有點bug；但聽交接我工作的同事排查我的實現的時候，說，「Schips的程式碼雖然看起來有點複雜，但是文檔裡面寫得很清晰，每一個部分都知道在做什麼。」

我想，我愛寫文檔和工作記錄的習慣大概就是這短短半年的入職期間養成的。

現在

我現在入職的公司是一家重視研發的公司YY，而且在研發投入上比較大方。

我能夠體會到這家公司與其他公司不一樣的地方，更像是一家互聯網公司。程式碼審查、開放的文檔平台、定期組織的培訓都是我所喜歡的。

其實評估一家技術型公司好不好，看它能留住多少經驗豐富的工程師就可以了。

技術方向上，在HR的努力勸說下，我從Linux驅動開始轉型高通平台的Android驅動。

其實做的事情差不多，但是會稍微多一點設計Android系統的開發以及高通平台本身的一些開發工具。

實際上，我對於自己有點不滿意；因為正處於一個自我能力認可的猶豫期：

• 以前我會抱著懷疑的態度，考慮：「這個問題是不是該不會是因為…吧？」；
• 現在，開始能夠比較有把握去地判斷：「這個問題應該是因為…」
• 我希望以後，可以更加堅定地說：「這個BUG應該是….的問題，你驗證一下xx看看是不是這樣子」

在這裡就不做展開了；等到後面再寫（😄）。

感想

關於技術人的知識管理

雖然我沒有這麼快想著轉型做技術管理，但我也會開始慢慢去看一些關於管理上的書。

《卓有成效的管理者》書中是這樣子主張的：每一位知識工作者其實都是管理者，而且卓有成效是每個管理者必須做到的事。書中認為所有負責行動和決策而且能夠提高機構工作效率的人，都應該像管理者一樣工作和思考。

管理是一門比較深奧的學問，看不見，摸不著；你不知道某個決策會馬上帶來什麼影響，只有時間會告訴你答案。就像是《未選擇的路》這首詩所寫的一樣，管理也是一種哲學。

限於能力，我暫時沒有什麼資格展開這個話題。

但其實，不管自己是不是管理者，其實對於每一位研發從業人員來說，起碼都要做到知識的閉環：(接觸)新知識--理解內化---對外輸出---(迭代)新知識。

不管大家的筆記是否和我一樣選擇公開，但是，我很主張要按階段總結自己的學習或者工作成果；你可以不公開，但是一定要寫，在寫的時候整理自己的思路。如果按「費曼學習法」的定義，對於一個知識點，只有你能夠表述清楚，你才能算是真正懂了。

如果能夠公開筆記，那是最好的，因為你所貢獻的東西，最終能夠給你帶來更大的價值。

管理筆記的方式多種多樣，總有適合自己的。我在這裡就不做推薦了，但是分享一下我自己的筆記平台：

以OneDrive作為網盤，以Typeora作為編輯器，以Obsdian作為搜索器，外加手動同步到部落格園這個方案。

關於需求溝通與技術交底

需求溝通

我們在工作中面對的很多溝通，實際上都可以看成是宏觀上的需求溝通；而不單單是技術上的某個需求。

在工作中，專業技能只是很小的一個部分。溝通才是最費時費力的事情。

腦海想的東西不一定能夠說出口，說出口的東西不一定能表達準確，表達準確不一定對方就完全聽到；

對方聽到的不一定是對方理解的，對方所理解的不一定是自己想的；

所以啊，溝通成功真的是很神奇。

因此，確認需求很重要。警惕「知識詛咒」——不要以為「你所以為的」事情，對方也知道。我在工作中經常確認一些細節，並不是因為自己沒有花時間去記，而是為了避免耽誤時間。

技術交底

再來說說技術交底吧。

「技術交底」這個詞，我是在寫專利文檔的時候接觸到的；但我願意用這個詞來給工作中的溝通重新定義：「在必要的時候，向需要了解某項技術的人，提供準確無誤的資訊，並且要求表達上沒有歧義。告知某項技術能夠做什麼，以及不能做什麼，能做到什麼程度」

為什麼？因為在溝通中的，對方不一定總是懂技術，你需要用他們能聽懂的話來讓他們理解你，從而來影響原本的需求。

換句話說，研發人員要對自己的技術負責，不要輕易被別人牽著鼻子走：萬一需求沒有溝通好，或者發現做不了；那麼就是在浪費時間和精力。

那麼同樣是溝通，會議也是一種常見的溝通方式，如何提高開會的效率？有沒有什麼比開會更有效率的行動？這個問題，希望大家去找到答案吧。

我倒是希望可以拒絕參加一些無關的會議（而不是陪跑）；我也希望有能力讓每一場會議變得有意義（而不是開了會，什麼都沒改變）。

之前看過別人是這麼說的：人多的會議不重要，重要的會議人不多。

關於加班、效率與時間管理

加班與效率

先說我的結論，我實名反對無意義的加班；理解有意義的加班，但也要平衡自己的精力，這樣子才能留點時間提升自己。

無意義加班：

有意義的加班，通常只有一種情況：項目緊急，不得不趕進度的時候。

但是實際上搞技術的研發人員都有一種自發的責任心，如果工作沒完成但又很緊急的時候，都會自發加班的（除非是很累了）。

研發人員如何評估工作進度也是一個話題，不展開了；但要給自己留有處理思考（異常問題、階段總結）的閑余。

讓一個沒有怎麼加過班的人加班，短時間內確實可以提高工作效率；但從長遠的角度來看，三方都輸了：

• 個人因為沒有充足的休息時間，輸掉了精力和工作效率，增加了離職的概率
• 部門因為員工積極性下降，輸掉了本來可以擁有的良好的工作氛圍
• 公司因為員工效率變差、人員流動頻繁而輸掉了本來可以省下來的人力成本。

根據《稀缺》這本書裡面提到的觀點，長期忙碌導致越來越忙：你會因為投入大量的時間處於忙碌的狀態，而忽視了本來能夠避免忙碌的因素。

另外，加班不是誰都適合的：

• 機械性重複的工作可以通過加班提高效率；比如流水線的普工。
• 創造性、研發的工作需要額定發散模式才有里程碑式的成果：正如我們程式設計師

定期總結很重要：無論是工作還是學習，無論自己有多忙，每完成一個里程碑，都建議整理一下；方便事後回顧，也容易形成一個良好的經驗復用。

時間管理

實際上，人的精力是有限的：一天真正高效的時間是充足睡眠以後的幾個小時左右；就算是每天只工作8個小時，也沒有全程高效。

合理利用有限的時間，讓自己變得更加高效是時間管理的目的。

當你擁有一段連續的時間塊，你可以就有條件進入專註模式。專註模式下在工作效率是最高的。所以，想辦法安排自己好自己的時間，讓它們能夠分成一個個時間塊。

當然，隨著你職位的變得越來高，你會發現屬於自己的時間越來越少；這個時候，如果你過於被動，你的成塊時間就少了；但同時，你也變得有權利來接受拒絕別人的安排（例如會議），所以，你應該及時合理地和對方溝通，安排出一個雙方都合適的時間。

合理區分任務優先順序：我不想提什麼四象限法則來說明你需要合理安排區分重要/緊急的事情；真正重要的是，分辨出事情的優先順序。

還是那句話，好好和需求方溝通，看看他們到底有多緊急。緊急的事情就抓緊做了；不緊急的事情由你主動來安排，不要讓別人破壞你的節奏。

在理想的情況下，我是這樣子的：

• 早上的工作效率最高，所以我會拿來處理一些比較難的工作；或者用於學習；這段時間我不希望別人打擾我

• 此後，我的工作效率變得一般，直到因為加班而低效。所以我也好把一些維護性的工作、小任務放在下午。

• 如果晚上有時間，又不覺得累的時候，我希望安排時間寫寫總結文檔、閱讀或者鍛煉一下身體。

我也和一位老同事交流過，他也很無奈自己白天的時間都在用來溝通，只有晚上才有時間幹活；我想這也是程式設計師的一種比較無奈的常態吧。

但是每一個人的作息都不一樣，我也不好評價，我只能說說我自己是什麼個情況，然後勸你惜命。

結語

實際上，我認為理想的工作情況是這樣子的：合理溝通需求可以適當減少不必要的工作量，保留時間去學習，進而提高自己的工作效率，反哺到崗位中，從而實現一個正向的循環。

而不是被動地工作，盲目的加班而放棄了提高工作效率的機會，從而越加班越低效，越低效越加班。

當然，話語權都是留給有能力的人，如果自己能力不夠，有再多的想法，又有誰care呢？

希望大家都能成為一名非典型的程式設計師，努力爭取你覺得正確的事情。

附錄：推薦書單

《軟技能：程式碼之外的生存指南》、《極客與團隊》、《黑客與畫家》、《卓有成效的管理者》

《稀缺》、《學會提問》、《深度工作》、《內在動機》

《非暴力溝通》、《被討厭的勇氣》

《印象筆記留給你的空間》

《練習的心態》、《瓦爾登湖》