我见过的最差程序员，差到让整个团队崩溃
作为一名在嵌入式领域摸爬滚打近十年的老兵，我见过太多奇葩程序员了。但要说最差的，非"赵工"莫属。
初见赵工
那是我从机械调剂到电子部门的第二年，公司接了个重要项目，需要开发一款基于STM32的工业控制系统。领导从总部借来一位"资深嵌入式专家"——赵工。
初见赵工时，他西装革履，一副成功人士模样。"我做过BAT核心项目，对单片机开发了如指掌"，他面试时的豪言壮语，让领导对他寄予厚望。
"独特"的编码风格
接手项目的第一周，赵工就展示了他的"实力"：
void Do_Something(void) { u8 a; u8 b; u8 c; u8 i; u8 j; u8 k; a=1; b=2; if(a==1) { for(i=0;i<10;i++) { if(b==2) { k = i + 1; //do something here } } } }没错，这就是他的编码风格——变量命名全是单字母，没有注释，缩进混乱，函数名毫无意义。当我问他这些变量代表什么意思时，他瞪了我一眼："代码就是写给机器看的，能运行就行，哪那么多讲究？"
"高效"的调试方法
赵工的调试方法更是"高效"。有一次系统死机，排查原因时，他直接往代码里塞了几十个printf：
printf("here1\n"); if(temp > 50) { printf("here2\n"); control_valve(); printf("here3\n"); } printf("here4\n");任何正常程序员都会使用条件断点或日志系统，但他偏要用这种原始方法。更可怕的是，调试完成后，这些垃圾代码常常被他忘记删除，留在生产代码中。
"革命性"的存储管理
记得有次他在处理EEPROM存储时，创造了这样的"杰作"：
// 存储用户配置 void save_config(void) { // 直接从0地址开始写，不管有没有其他数据 EEPROM_Write(0, (uint8_t*)&global_config, sizeof(global_config)); } // 加载配置 void load_config(void) { // 没有任何校验，直接读取 EEPROM_Read(0, (uint8_t*)&global_config, sizeof(global_config)); }没有地址规划，没有数据校验，没有版本管理。当我提醒他这会导致数据混乱时，他不以为然："又不是大型系统，用不着那么复杂。"
结果可想而知，产品一上线，用户配置经常莫名其妙丢失或混乱。
远离坑货机会
技术大厂，前端-后端-测试，新一线和一二线城市等地均有机-会，感兴趣可以试试。待遇和稳定性都不错~
"高级"的内存管理
在一个需要处理大量传感器数据的模块中，他写出了这样的代码：
void process_sensor_data(void) { // 每次分配固定大小，用完不释放 uint8_t *buffer = malloc(1024); // 处理数据... // 没有free操作 }这个函数每分钟会被调用几十次，内存泄漏严重。当系统运行几小时后必然崩溃。我指出这个问题时，他竟然说："单片机会自动回收内存的，不用担心。"
我当时就懵了，这种基础常识都不懂，他是怎么通过面试的？
"创新"的版本控制
提到版本控制，赵工也有独到见解。公司用Git管理代码，他却坚持用自己的方式：
- 从不写commit信息，或者就写个"update"
- 本地修改后直接push到master分支
- 代码出问题了，就复制整个项目文件夹重命名为"project_backup_0415"
有一次他把整个主分支代码弄坏了，急得团队其他成员直冒冷汗。当问他为什么不用分支开发时，他理直气壮："那太麻烦了，我一个人开发用不着那些东西。"
"高超"的团队协作
赵工的团队协作能力堪称一绝。记得有次我接手他的一个模块进行扩展，打开代码后惊呆了：
// 神秘函数 void xyz(void) { u16 m = get_value(); if(m > 30) { op(); } else if(m <= 30 && m > 20) { op2(); } else { if(flag) { op3(); } } }完全看不懂这函数是干什么的！没有文档，没有注释，变量名全是缩写，函数名毫无意义。我只好硬着头皮找他问。
他却说："代码写出来就是给机器看的，你看不懂是你水平问题。再说了，这是我的核心竞争力，如果写得太清楚，公司还要我干嘛？"
这种"核心竞争力"理论让我哭笑不得。在我看来，真正的核心竞争力是创造价值的能力，而不是制造混乱的能力。
灾难的项目结局
最后这个项目如何收场？你们猜到了。
原定三个月的项目拖了半年，客户不断投诉系统不稳定。在一次重要演示中，系统当场崩溃，客户大怒。公司损失了一个重要客户，也赔了一大笔违约金。
赵工却毫不愧疚，反而抱怨环境问题："肯定是测试环境不对，我本地运行得好好的。"
最终，他被公司礼貌地送回了总部，项目由我和另外两位同事重构。我们花了两个月才把这烂摊子收拾干净。
反思：什么造就了"最差程序员"
回想这段经历，我总结赵工这类"最差程序员"的特质：
- 技术傲慢：自以为是，不接受批评，拒绝学习新知识
- 基础薄弱：缺乏编程基本素养，连最基础的内存管理、代码规范都不遵守
- 自私封闭：视代码为个人财产，故意设置理解障碍
- 责任推卸：问题永远是别人的，从不反思自己
- 短视功利：只关心眼前能跑，不考虑长期维护
这种程序员不仅技术差，更可怕的是态度差。他们像一颗定时炸弹，迟早会给团队和产品带来灾难。
与之对比：什么是好程序员
我27岁进入世界500强外企时，遇到一位让我敬佩的技术主管李工。他的代码风格截然不同：
/** * @brief 处理温度传感器数据并控制阀门 * @param temperature 当前温度值(摄氏度) * @return 操作是否成功 * @note 当温度超过临界值时，会自动关闭阀门 */ bool processTempAndControlValve(float temperature) { // 安全检查 if (!isSensorValid(SENSOR_TEMP)) { logError("Temperature sensor not valid!"); return false; } // 温度过高，关闭阀门 if (temperature > CRITICAL_TEMP_THRESHOLD) { logWarning("Critical temperature detected: %.2f°C", temperature); return closeValve(VALVE_MAIN); } // 正常温度范围 return true; }他的代码：
- 命名清晰，一看就懂
- 有完善注释和文档
- 考虑异常情况
- 模块化，便于测试和维护
- 遵循团队代码规范
更重要的是，他从不吝啬分享知识。每周五下午，他都会组织技术分享会，讲解嵌入式Linux的各种难点。正是在他的影响下，我开始自学Linux，并在28岁时开始写技术公众号分享所学。
职场启示：远离"赵工"，培养好习惯
这些经历让我深刻认识到，成为好程序员不仅关乎技术，更关乎态度和习惯。这也是我30岁创业后，在培训和咨询中一直强调的核心理念。
在我的小公司里，我们有严格的代码审查制度，无论资历高低，代码必须符合规范才能合并。有位刚入职的年轻人抱怨："写那么多注释太浪费时间了！"我给他看了赵工项目的代码和我们后来重构的对比，他立刻理解了。
好的编程习惯就像复利，短期看不到效果，长期却能造就天壤之别。这也是我从嵌入式开发一路走来的深刻体会。
结语
如果你在团队中遇到了"赵工"式的程序员，请保持警惕，远离这种技术债务制造机。如果你担心自己可能有类似倾向，请反思并改变，这对你的职业生涯至关重要。
真正的编程高手，不仅代码写得好，更能让团队变得更好。就像我在二线城市靠技术和分享积累第一个百万时所感悟的：技术能力决定下限，协作能力决定上限。
作为一个从机械转行到嵌入式的非科班程序员，我深知基础扎实和态度端正的重要性。希望每位程序员都能远离"最差"，走向更好的自己。
你们遇到过什么样的奇葩程序员？欢迎在评论区分享，我们一起吐槽一下。
——转载自：良许Linux
