加班内卷的IT行业,我选择躺平

代码收藏夹
2025-12-21 10:20
阅读 2713

今天是周三,早上8点刚泡好第三杯咖啡,窗外天色微亮,办公室里只有我和保洁阿姨。这场景要是让前司同事看到,怕是要笑我“装勤奋”——毕竟在上一家公司,晚上10点不走都不好意思打卡。可自从两个月前跳槽到这家三线城市的互联网小厂当后端技术负责人,我的生活节奏像被按下了“降速键”。

不是我不卷了,而是我发现:卷不动了,也卷不起价值了


刚来这家公司时,其实我也带着“大厂遗风”。第一个月,为了给新团队立威(或者说立个靠谱人设),我主动揽下了一个核心模块的重构任务。那是个典型的“祖传代码”项目:PHP写的API接口混着Java后端逻辑,数据库连表查询动不动就跑出3秒+,还时不时因为连接池耗尽把整个服务干趴。

产品那边催得急:“老板说这个月必须上线新功能,不然融资进度受影响。”
测试那边天天@我:“这个接口又500了,你们后端能不能稳一点?”
运维更绝:“你再这么搞,K8s节点资源告警邮件都要把我邮箱塞爆了。”

我一度以为,只要我多熬几个夜、多改几版代码、多怼几个产品经理,事情就能变好。于是那两周,我每天凌晨两点才睡,白天还要开需求评审、技术方案会、线上事故复盘……整个人像被抽干了,写出来的代码反而越来越烂——上周五晚上,我居然在一个简单的DTO转换里漏掉了字段校验,导致用户注册数据大面积丢失。那一刻,我盯着屏幕上刺眼的 NullPointerException,真的想砸电脑。

但最让我崩溃的不是Bug,而是没人觉得这是个问题

项目经理轻描淡写地说:“小问题,加个补偿脚本就行。”
CTO在周会上夸我:“老张最近很拼啊,值得表扬。”
连我自己都开始怀疑:是不是不够努力?是不是抗压能力太差?

直到某天深夜,我在查一个诡异的内存泄漏问题,突然意识到一件事:我们拼命消耗自己的时间和精力,换来的只是系统暂时不崩,而不是真正的进步。而这种“救火式开发”,本质上是在浪费公司最宝贵的综合资源——不仅是服务器、带宽这些硬件资源,更是团队成员的脑力、情绪和创造力。


资源有限,别把人当耗材

在大厂时,我们常说“用钱买时间”。但在三线城市的小公司,钱不多,人更少。一个后端团队就5个人,要支撑三个产品线、几十个微服务。这时候如果还靠“加班堆人头”来解决问题,无异于饮鸩止渴。

我开始重新思考“效率”到底是什么。

以前我觉得效率=单位时间产出代码行数,现在我觉得效率=用最少的资源解决最核心的问题

举个例子:之前我们有个定时任务,每天凌晨跑全量用户行为分析,占用了大量数据库IO和CPU。运维天天抱怨资源不够,申请扩容又被财务驳回。我原本打算重写调度逻辑、引入分片、优化SQL……但后来一想:这玩意儿真的需要全量跑吗?

和产品聊了之后发现,90%的分析结果根本没人看。最终我们砍掉了70%的计算字段,改成按需触发+缓存机制。服务器负载直接降了60%,运维终于不用半夜接告警电话了。

优化前 优化后
每日凌晨2点全量跑 用户点击“查看报告”时触发
占用DB CPU 80%+ 平均占用<20%
需要8核16G机器×3台 4核8G机器×2台足够
团队每周处理3起相关故障 近一个月零故障

你看,不是靠加班,而是靠“不做无用功”


躺平不是摆烂,是精准发力

很多人一听“躺平”就以为是摸鱼、划水、不干活。但我想说的“躺平”,其实是拒绝无效内卷,把力气用在刀刃上

比如我现在每天8点到公司,第一件事不是打开IDE,而是列清楚今天必须完成的三件事。超过这三件?对不起,要么优先级不够,要么需求不合理。我不再为了“显得很忙”而开会,能异步沟通的绝不拉会;不再为了“技术情怀”而过度设计,能用简单方案解决的绝不上微服务。

上周,产品提了个需求:要在用户主页加个“AI智能推荐”功能。按照以前的我,可能马上开始调研Embedding模型、向量数据库、实时推理服务……但这次我直接问:“这个功能的核心指标是什么?预期提升多少转化率?”

对方支支吾吾半天,最后承认:“老板看了竞品有,我们也得有。”

我笑了笑:“那不如先做个静态Banner,成本低、上线快,还能快速验证效果。真有效再上AI也不迟。”

结果呢?Banner上线一周,点击率不到1%。需求自然凉了。省下的开发时间,我拿去修复了一个积压半年的支付对账Bug——这才是真正影响公司营收的问题。


后端人的“反内卷”生存指南

作为后端工程师,我们常常陷在“系统稳定性”的焦虑里。但稳定≠无限兜底。我的经验是:

  1. 设立技术底线
    比如:拒绝在没有单元测试的情况下上线核心交易逻辑;拒绝在高峰期部署未经压测的服务。这不是矫情,是对系统负责。

  2. 用数据说话
    当有人说“加个字段很简单”,你就拿出历史变更记录:“上次类似改动引发3次线上故障,平均修复耗时4小时。” 用事实打破“简单论”。

  3. 学会说“不”
    不是所有需求都要接。尤其当它明显违背技术常识或资源预算时。我现在的口头禅是:“可以做,但需要评估ROI(投入产出比)。”

  4. 保护自己的能量
    我给自己定了一条铁律:晚上9点后不回工作消息(紧急事故除外)。周末除非发布重大版本,否则不碰电脑。这两个月下来,不仅精神状态好了,代码质量反而提升了——因为大脑终于有空间思考,而不是机械执行。


关于AI学习的一点私心

坦白讲,我最近学AI,一部分原因确实是“被时代推着走”,但更多是想找到一条不用靠体力取胜的技术路径

以前觉得AI离后端很远,但现在发现,很多重复性工作完全可以用LLM自动化。比如自动生成SQL注释、解析日志定位异常、甚至辅助写单元测试。上周我就用LangChain搭了个小工具,自动从Jira需求里提取关键字段生成接口文档初稿,省了我至少2小时/天的手工劳动。

技术人的终极“躺平”,应该是用更聪明的工具,让自己从重复劳动中解放出来


写在最后

我知道,在一线城市的大厂,可能这种“慢节奏”会被视为不上进。但对我们这种三线城市的中小团队来说,资源有限,更经不起瞎折腾。与其用加班掩盖问题,不如直面本质:哪些事值得做?哪些事可以不做?哪些事能用更少的代价做好?

我已经不再为“没加班”而愧疚。相反,当我能在下午6点准时下班,陪孩子吃晚饭,晚上还有精力读完一篇论文、跑个步、甚至写这篇博客——我觉得自己才是真正“高效”的程序员。

毕竟,代码会过时,系统会重构,但人的时间和健康,一旦透支,就再也补不回来了

所以,如果你也在被内卷压得喘不过气,不妨试试“战略性躺平”:
不是不干,而是只干值得干的事

共勉。

评论 0

最热最新
暂无评论
代码收藏夹Lv.1
0
影响力
0
文章
0
粉丝