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

刷题 | LeetCode算法刷题神器,看完 BAT 随你挑!
有收获?希望老铁们来个三连击,给更多的人看到这篇文章
推荐阅读:
欢迎关注我的博客:良许嵌入式教程网,满满都是干货!