当前位置 博文首页 > 黄树超：嵌入式行业入行3年的一点小感想
距离18年毕业典礼那天，到今天刚好过去了3个年头。重新去回顾这几年来工作上经历，我觉得还是有必要小小地记录一下；毕竟，没有记录的日子，等于未曾发生。
下述的公司都以缩写代替。
我还记得一开始出来工作的时候，编程能力只停留于计算机2级C语言及格线的水平线左右，外加只会一点点Linux命令行操作；经过自己的争取和面试官的包容，我来到了GSK。
在培养人才的角度来看，GSK是一家很好的公司，现在想想，和部门内的同事相处的日子依旧很融洽。我们部门中的每一位同事，都在嵌入式行业中各个领域有所建树；我不止一次地和别人提到过他们在下面行业各自的成就：
以及，部门老大在知识管理以及技术管理方面的教导，让我很受用，以及他对目标的毅力让我觉得很钦佩的，要把事情做到极致，起码要像他那样子。
可以说，正是有了他们，我对行业的了解才会比较深刻。
那个时候，离开学校没多久的我，对于嵌入式行业的还停留在老旧的理论水平；但在部门的培养下（主要是因为我的直属领导），我对嵌入式行业、尤其是工控方面的开始有了自己的理解。以至于现在的我，对于产品中必要的实时性、可靠性还是很敏感。
我在工作中的大部分时候是帮其他部门开发一些底层的组件，确认他们在驱动程序的使用上是否存在问题。
因为初出茅庐，我在遇到不懂的问题，经过思考以后都会去问同事Alex。
Alex每次听到我的疑问以后，总是会用手摸下巴，低头思考一会，并问我，“你的需求是什么，你想实现什么？”
有经验的工程师不会专门去满足你的需求，他会先确认你要实现的结果，然后反馈给你一个更好的方案；或者评估过认为可行性有问题而直接拒绝你。
我也见过他当面拒绝一位心高气傲的其他部门老工程师的需求；我很佩服他知道什么必须做，什么不应该做。
待会我们说一下“沟通”的话题。
出于独立的态度，当时的我也不太喜欢去求助别人。（但在当时，其实还是应该多多学习，积极提问；我有点后悔当时没有好好珍惜当时的机会；但这是后话了）
后来，我担心成长速度太慢而离开了这家公司；但在离开的时候，我也勉勉强强能够搞点Linux驱动的东西了；但也只是皮毛。想着成长快一点，我又跑到了一家小公司。离开的时候，领导听说我要从黄埔跑去荔湾，笑着问我是不是跨度有点大。
那个时候，算上实习生，在我们技术经理还没离职之前，我们技术部共有6个人。我负责驱动，还有其他同事负责web以及基于海思SDK的应用程序开发。
相比大公司对人才成长的包容，小公司GK对于研发结果的渴望来得更为强烈，老板巴不得你每天坐在工位上，从早干到晚。
后面也会提到关于我对加班的看法。
因为不懂技术的人不知道如何量化研发人员的贡献，所以只会用所谓的工作时间来衡量你的产出。说实话，我一直不喜欢这一点，这属于一种管理无能。我赞同《极客与团队》书中的这个观点：技术Leader应该要有自己的底气，来cover自己的团队在一个更加稳定的环境下安心地工作以及成长。
因为产品不够稳定就发布了，以至于发生了很多从现在看起来“算是有趣”的事情：
销售要求第二天早上就要发货，可是到了晚上10点的时候，我还在紧急排查一个产品问题；当时心里真的很着急；结果我的领导告诉我，“遇到实在是搞不定的问题，你先休息一下，可能待会就有思路。”，第二天早上，我一大早来到公司，排查到是因为文件系统中库的软链接丢了，链上以后就按时发货了。
有几次我们需要去客户现场出差；和实施工程师一起在使用自己部门开发的产品的时候，我才发现：搞产品不能依赖于研发人员的思维，要从用户的角度来看待你写的产品——因为他们并不关心你的内部实现有多trickly，你能满足他们的需求，而且稳定可用就算是满分了。也是从那个时候起，我知道一线的同事其实是很不容易的，能积极配合的工作一定要积极配合，同是打工人，没必要相互揣着一副自以为是的架子。
我还记得和我们领导因为产品在推流的时候出问题，便一起跑去浙江现场去看。那个时候两个人住在酒店里，人生地不熟，我小声“啧”了一下当时在电梯里吸烟的两个痞子。事后我的领导告诫我，不要去惹这些人，因为你如果得罪了那些人，对你来说很不值得，你不会去犯罪，但他们不一定也这么想；而且，他们的时间不如你的时间值钱。
受限于产品线的平台，很快在驱动方面我就没有什么发展的空间了，而且领导想让我往Windows-SDK应用靠拢；因此我权衡了一下，选择了离开。那个时候我在迷茫要不要继续搞底层驱动，犹豫过一两次往应用开发方向去靠拢。
所以，当时的我在空闲的期间巩固了自己的Qt以及c/c++的语法与设计模式；虽然最后没有往应用方向继续发展，所幸我在有必要的时候开发一些小工具来改进我的工作效率。
我所学习的应用层上的东西，在后面分析安卓源码的时候，尤其是看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系统的开发以及高通平台本身的一些开发工具。
实际上，我对于自己有点不满意；因为正处于一个自我能力认可的犹豫期：
在这里就不做展开了；等到后面再写（??）。
虽然我没有这么快想着转型做技术管理，但我也会开始慢慢去看一些关于管理上的书。
《卓有成效的管理者》书中是这样子主张的：每一位知识工作者其实都是管理者，而且卓有成效是每个管理者必须做到的事。书中认为所有负责行动和决策而且能够提高机构工作效率的人，都应该像管理者一样工作和思考。
管理是一门比较深奥的学问，看不见，摸不着；你不知道某个决策会马上带来什么影响，只有时间会告诉你答案。就像是《未选择的路》这首诗所写的一样，管理也是一种哲学。
限于能力，我暂时没有什么资格展开这个话题。
但其实，不管自己是不是管理者，其实对于每一位研发从业人员来说，起码都要做到知识的闭环：(接触)新知识--理解内化---对外输出---(迭代)新知识。
不管大家的笔记是否和我一样选择公开，但是，我很主张要按阶段总结自己的学习或者工作成果；你可以不公开，但是一定要写，在写的时候整理自己的思路。如果按“费曼学习法”的定义，对于一个知识点，只有你能够表述清楚，你才能算是真正懂了。
如果能够公开笔记，那是最好的，因为你所贡献的东西，最终能够给你带来更大的价值。
管理笔记的方式多种多样，总有适合自己的。我在这里就不做推荐了，但是分享一下我自己的笔记平台：
以OneDrive作为网盘，以Typeora作为编辑器，以Obsdian作为搜索器，外加手动同步到博客园这个方案。
我们在工作中面对的很多沟通，实际上都可以看成是宏观上的需求沟通；而不单单是技术上的某个需求。
在工作中，专业技能只是很小的一个部分。沟通才是最费时费力的事情。
脑海想的东西不一定能够说出口，说出口的东西不一定能表达准确，表达准确不一定对方就完全听到；
对方听到的不一定是对方理解的，对方所理解的不一定是自己想的；
所以啊，沟通成功真的是很神奇。
因此，确认需求很重要。警惕“知识诅咒”——不要以为“你所以为的”事情，对方也知道。我在工作中经常确认一些细节，并不是因为自己没有花时间去记，而是为了避免耽误时间。
再来说说技术交底吧。
“技术交底”这个词，我是在写专利文档的时候接触到的；但我愿意用这个词来给工作中的沟通重新定义：“在必要的时候，向需要了解某项技术的人，提供准确无误的信息，并且要求表达上没有歧义。告知某项技术能够做什么，以及不能做什么，能做到什么程度”
为什么？因为在沟通中的，对方不一定总是懂技术，你需要用他们能听懂的话来让他们理解你，从而来影响原本的需求。
换句话说，研发人员要对自己的技术负责，不要轻易被别人牵着鼻子走：万一需求没有沟通好，或者发现做不了；那么就是在浪费时间和精力。
那么同样是沟通，会议也是一种常见的沟通方式，如何提高开会的效率？有没有什么比开会更有效率的行动？这个问题，希望大家去找到答案吧。
我倒是希望可以拒绝参加一些无关的会议（而不是陪跑）；我也希望有能力让每一场会议变得有意义（而不是开了会，什么都没改变）。
之前看过别人是这么说的：人多的会议不重要，重要的会议人不多。
先说我的结论，我实名反对无意义的加班；理解有意义的加班，但也要平衡自己的精力，这样子才能留点时间提升自己。
无意义加班：
| case | reason |
|---|---|
| 就算是今晚/周末不加班完成的工作，也不会影响到项目的进度 | 没必要 |
| 本来应该用于休息，学习却用来工作的时间 | 低效，性价比低 |
| 公司规定强制的加班，哄领导开心 | 消磨对待工作的积极性 |
有意义的加班，通常只有一种情况：项目紧急，不得不赶进度的时候。
但是实际上搞技术的研发人员都有一种自发的责任心，如果工作没完成但又很紧急的时候，都会自发加班的（除非是很累了）。
研发人员如何评估工作进度也是一个话题，不展开了；但要给自己留有处理思考（异常问题、阶段总结）的闲余。
让一个没有怎么加过班的人加班，短时间内确实可以提高工作效率；但从长远的角度来看，三方都输了：
根据《稀缺》这本书里面提到的观点，长期忙碌导致越来越忙：你会因为投入大量的时间处于忙碌的状态，而忽视了本来能够避免忙碌的因素。
另外，加班不是谁都适合的：
定期总结很重要：无论是工作还是学习，无论自己有多忙，每完成一个里程碑，都建议整理一下；方便事后回顾，也容易形成一个良好的经验复用。
实际上，人的精力是有限的：一天真正高效的时间是充足睡眠以后的几个小时左右；就算是每天只工作8个小时，也没有全程高效。
合理利用有限的时间，让自己变得更加高效是时间管理的目的。
当你拥有一段连续的时间块，你可以就有条件进入专注模式。专注模式下在工作效率是最高的。所以，想办法安排自己好自己的时间，让它们能够分成一个个时间块。
当然，随着你职位的变得越来高，你会发现属于自己的时间越来越少；这个时候，如果你过于被动，你的成块时间就少了；但同时，你也变得有权利来接受拒绝别人的安排（例如会议），所以，你应该及时合理地和对方沟通，安排出一个双方都合适的时间。
合理区分任务优先级：我不想提什么四象限法则来说明你需要合理安排区分重要/紧急的事情；真正重要的是，分辨出事情的优先级。
还是那句话，好好和需求方沟通，看看他们到底有多紧急。紧急的事情就抓紧做了；不紧急的事情由你主动来安排，不要让别人破坏你的节奏。
在理想的情况下，我是这样子的：
早上的工作效率最高，所以我会拿来处理一些比较难的工作；或者用于学习；这段时间我不希望别人打扰我
此后，我的工作效率变得一般，直到因为加班而低效。所以我也好把一些维护性的工作、小任务放在下午。
如果晚上有时间，又不觉得累的时候，我希望安排时间写写总结文档、阅读或者锻炼一下身体。
我也和一位老同事交流过，他也很无奈自己白天的时间都在用来沟通，只有晚上才有时间干活；我想这也是程序员的一种比较无奈的常态吧。
但是每一个人的作息都不一样，我也不好评价，我只能说说我自己是什么个情况，然后劝你惜命。
实际上，我认为理想的工作情况是这样子的：合理沟通需求可以适当减少不必要的工作量，保留时间去学习，进而提高自己的工作效率，反哺到岗位中，从而实现一个正向的循环。
而不是被动地工作，盲目的加班而放弃了提高工作效率的机会，从而越加班越低效，越低效越加班。
当然，话语权都是留给有能力的人，如果自己能力不够，有再多的想法，又有谁care呢？
希望大家都能成为一名非典型的程序员，努力争取你觉得正确的事情。
《软技能：代码之外的生存指南》、《极客与团队》、《黑客与画家》、《卓有成效的管理者》
《稀缺》、《学会提问》、《深度工作》、《内在动机》
《非暴力沟通》、《被讨厌的勇气》
《印象笔记留给你的空间》
《练习的心态》、《瓦尔登湖》
