背景

距离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++的语法与设计模式；虽然最后没有往应用方向继续发展，所幸我在有必要的时候开发一些小工具来改进我的工作效率。

我所学习的应用层上的东西，在后面分析安卓源码的时候，尤其是看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系统的开发以及高通平台本身的一些开发工具。

实际上，我对于自己有点不满意；因为正处于一个自我能力认可的犹豫期：

• 以前我会抱着怀疑的态度，考虑：“这个问题是不是该不会是因为…吧？”；
• 现在，开始能够比较有把握去地判断：“这个问题应该是因为…”
• 我希望以后，可以更加坚定地说：“这个BUG应该是….的问题，你验证一下xx看看是不是这样子”

在这里就不做展开了；等到后面再写（