技术员工作经历

2016年夏天，技术我入职一家做工业传感器的员工公司，岗位叫“嵌入式软件工程师”。作经面试时我说自己懂C语言和单片机，技术实际上只会点灯和串口打印。员工入职第三天，作经组长扔给我一块带CAN总线的技术板子，让我把报文解析出来。员工我对着数据手册看了两小时，作经连寄存器地址都找不全。技术最后是员工隔壁工位的老赵看不过去，丢过来一份他写好的作经底层驱动，说：“别从头造轮子，技术先改参数。员工”

那次之后我明白一个道理：技术工作里，作经快速理解现有代码比闷头写新代码更重要。老赵的驱动写得不算优雅，但注释特别详细，每个函数上面都标着“为什么这么写”和“踩过什么坑”。我照着改了一周，把波特率、过滤掩码、数据长度挨个调通，第一次在示波器上看到稳定的波形时，那种成就感比大学考满分还实在。

不过真正让我长记性的是一次现场故障。客户说设备偶发死机，我们远程抓了三天日志都没复现。我主动申请去现场，到了才发现，工厂车间里有台大功率变频器，每次启动时电磁干扰特别强，把CAN总线的信号直接打乱了。我蹲在配电柜旁边观察了一下午，发现死机时间点和变频器启动时间完全重合。解决办法其实很简单——在总线两端各加一个120欧姆的终端电阻，再把屏蔽层单端接地。前后花了不到半小时，但排查用了整整四天。

这活儿教会我：很多技术问题不是靠代码解决的，得看物理环境和现场条件。后来我再写通信程序，都会先问一句：“这设备装在什么环境？旁边有没有大电机、变频器、电焊机？”这些细节，数据手册上永远不会写。

到了第三年，我开始带新人。有个小伙子特别聪明，写算法很快，但总喜欢把功能封装得很抽象。有一次他写了个温度补偿模块，接口参数有七个，调用顺序稍错就出数据异常。我让他重构，他还不乐意，觉得别人看不懂是水平问题。后来我拿他写的模块去跑老赵留下的测试用例，果然挂了三项。我把自己当年看老赵代码的经历讲给他听——代码是给人看的，顺便让机器执行。他沉默了一会儿，第二天交了个版本，参数砍到三个，每个都有默认值，注释里写明了适用场景。

现在我自己也写注释，但风格和老赵不太一样。老赵喜欢写“为什么”，我更喜欢写“这里曾经出过什么bug”。比如某段滤波算法旁边，我会标注：“2020年3月，客户反馈数据跳变，原因是采样时序和中断优先级冲突，改这里时别动中断配置。”我觉得这种注释更像给未来的自己留的便条，比教科书式的说明有用得多。

回头看看这几年，真正让我进步的从来不是什么高深理论，而是一次次被现实打脸后的总结。搞技术这行，书本知识只是入场券，现场、老同事、甚至客户的抱怨，才是真正的老师。我现在带人时也常说：“别怕出问题，怕的是同一个问题出第二次。”这话听着普通，但能做到的人真不多。

很赞哦!（9447）