程序员如何接受工作内容毫无意义？

知乎上有人问：程序员如何接受工作内容毫无意义？

他举了一堆例子。按钮文案从「氛围」改成「空间」，又改回来。一个按钮被疯狂点击后偶尔闪烁，测试提了bug，但觉得用户根本不会这么操作。git提交信息格式不对被打回。周报提交了领导根本不看。

这些抱怨我见过太多了。每次看到，反应都一样：觉得工作没意义的人，十有八九不是工作本身没意义，是他还没走到能接触有意义工作的阶段。

你觉得没意义的事，可能是你没看懂

先说按钮被疯狂点击这个。

提问者觉得「用户根本不会那样操作」，这个判断本身就暴露了经验不足。线上环境跟本地开发完全不是一回事。接口响应时间正常的时候，用户确实不会连续点。问题在于，接口不可能永远正常。数据库慢查询、网络抖动、第三方服务超时，任何一个环节出状况，响应时间就会从几百毫秒变成几秒甚至十几秒。用户看到页面没反应，本能反应就是再点一下，再点一下。俗称【一阳指】。

这种问题的解法分两层，前端加防抖，后端做幂等，缺一不可。前端的防护随时可以被绕过（比如用户刷新页面重新点击），后端的幂等才是兜底。

前端的处理：

JavaScript 复制代码

// 用户点击后立即禁用按钮，等接口返回后再恢复
button.disabled = true;
try {
  await submitOrder(params);
} finally {
  button.disabled = false;
}

后端的幂等处理，常见做法是用唯一请求令牌。前端进入页面时先请求一个令牌，提交时带上，后端用这个令牌做去重。同一个令牌只处理一次，后续重复请求直接返回第一次的处理结果。

这件事的关键不在于技术方案多复杂，而在于你有没有意识到这是一个需要处理的场景。提问者觉得「用户不会这么操作」，恰恰说明他还没经历过线上事故，不知道用户在异常情况下的行为是不可预测的。

再说git提交信息格式。

有人觉得这是形式主义，提交信息写个「fix」「update」也能跑，何必在格式上较真。这种想法在本地开发的时候确实看不出问题，因为你只管自己那一亩三分地，用不着翻提交记录。但是如果是leader的话，他是会看的，就比如我，我是看的。

另外到了线上出故障了，我也是会去看团队的人提交了啥功能的。

一条好的commit信息长这样：

Markdown 复制代码

fix bug: 订单列表分页查询在数据量超过10万时响应超时，添加索引并优化SQL

一眼就能看出改了什么、为什么改。

我现在带的团队也有人commit信息写得随意，同样会提醒。

至于把按钮文案从「氛围」改成「空间」又改回来这种事，确实让人烦。产品需求反复变更，在任何公司都存在。背后的原因可能是用户调研的结论变了，可能是AB测试的数据不支持改动，也可能是产品经理还在摸索最优方案。

这种事你改不了，也没必要为此生气。做开发这行，需求变更是工作的一部分，不是工作以外的干扰。与其纠结「为什么又改回来了」，不如想想能不能做成配置化，下次改文案直接改配置，不用动代码发版。这才是一个有经验的开发者面对这类问题时的反应。

不是工作没意义，是信任还没建立

每个团队里都有简单任务和复杂任务。复杂的模块，比如支付系统的核心链路、高并发场景下的库存扣减、涉及多方对接的数据同步，这些模块出了问题影响面大，修复成本高。leader把这些模块交给谁做，取决于一个东西：信任。

信任不是靠工龄换来的，不是你干了一年就自动获得的。信任来自leader对你交付质量的持续观察。你之前做的每一个小任务，改的每一个bug，写的每一行代码，都在帮leader建立对你的判断：这个人靠不靠谱，交出去的东西要不要再检查一遍，遇到问题会不会提前说。

leader不把复杂模块交给新人，不是看不起谁。换位想一下：一个高风险的模块，出了问题直接影响线上用户，leader自己也要承担责任。他对你的代码质量、设计能力、沟通习惯都还没有足够的了解，凭什么拿线上的稳定性去赌？他的选择必然是交给他已经验证过的人。

这跟你能力强不强没有直接关系。你可能确实很强，但leader还不知道。他需要通过一段时间的观察来验证。

有人可能会说：「我干了一年了，还在改文案，是不是leader有问题？」

这要看你过去一年做了什么。如果每个交到你手上的任务都做到了不留尾巴、不需要别人返工、有问题提前暴露，那leader大概率已经在给你更复杂的任务了。如果一年过去了还是只能做最简单的事，该反思的可能不是leader的安排，而是自己交付的质量是不是真的达到了预期。

从新人到核心成员，信任的建立是有阶段的，每个阶段需要展现的能力不一样：

信任阶段	典型任务特征	关键行为
观察期	改文案、修样式、写单元测试	每个任务交付到位，不留尾巴，不需要人催
磨合期	独立负责小功能模块、处理有一定复杂度的bug	主动同步进度，遇到阻塞提前暴露，不闷头搞
信任期	负责完整业务模块、参与技术方案评审	能给出有依据的技术判断，不只是等安排
核心期	架构设计、技术选型、带新人	对业务全局和技术体系都有自己的判断

对照这张表看看自己在哪个阶段，比抱怨工作没意义有用得多。停在观察期不往前走，多数情况不是没机会，是上一个阶段的要求还没做到位。

想做有挑战的事，主动开口

等leader来问你「想不想试试更复杂的任务」，这种事极少发生。leader每天要处理的事情很多，不太会主动关注每个人的成长诉求。想做更有挑战的工作，得自己说出来。

沟通的方式有讲究。不要说「我觉得现在的工作没意思，想做点有意义的」。这句话在leader听来等于在说：你嫌弃当前的工作，同时在质疑他的分工安排。

可以换个说法：「最近的任务我感觉上手比较顺了，想看看有没有稍微复杂一点的模块可以让我试试。遇到问题我会及时沟通和求助。」

两种表达的区别在于，前者是在抱怨，后者是在表达意愿，同时给了leader一个安全感：遇到问题会及时沟通，不会一个人闷头搞砸。

有一个前提条件。你手上的简单任务得先做好了。如果改文案的需求都能出纰漏，git提交信息都写不规范，这时候跟leader说想做复杂模块，效果适得其反。leader不会觉得你有上进心，只会觉得你连基本功都不扎实就想跳级。

给你难的，你能搞定吗

换一个角度想这个问题。假设leader今天就给你一个任务：某个接口的QPS从500提到5000，怎么做？

你能说清楚瓶颈在哪里吗？是数据库查询慢、是锁竞争、是网络IO、还是序列化开销？定位到瓶颈之后，是加缓存、是改异步、是分库分表、还是优化SQL？每种方案的适用条件和副作用都清楚吗？

如果这些问题现在答不上来，那改按钮文案这个阶段对你来说就不是浪费时间。你需要用这些相对简单的任务去熟悉项目的代码结构、业务逻辑、技术栈的用法。等你对项目足够熟悉了，对常见的技术方案有了判断力，再去做复杂模块才不至于翻车。

代码规范、git规范、沟通习惯这些东西，看着跟技术能力无关，实际上是做复杂项目的地基。一个连commit信息都写不好的人，做复杂模块时的代码注释、方案文档、上线检查单也大概率会有问题。基本功不是做完简单任务就自动获得的，是在做简单任务的过程中刻意练出来的。

小结

觉得工作没意义这种心态，干了两三年的开发者身上尤其常见。过了最初的新鲜期，技术上够用但不深入，业务上了解但没吃透，处在一个不上不下的位置。这个阶段其实是最关键的分水岭。有的人选择应付，觉得反正做的都是杂活，差不多得了。有的人在每个小任务上打磨自己的工程习惯和技术判断力。两三年后，两种人的差距会大到彼此都认不出来。

职场里最亏的不是能力不足，是能力还不够但自己以为已经够了。这种认知偏差会让人停止成长，因为他觉得问题出在环境上，不在自己身上。承认自己还有很大的成长空间，比承认工作没意义要难得多，但也有用得多。

最近在知乎出了「应付6000万会员的秒杀系统专栏」和「几亿用户,百万并发的C端商品系统实战」专栏，感兴趣的可以订阅一下。至于知识星球的，可以搜：

老码头的技术浮生录

它是一个能实际帮你解决难题的星球。有问题的，找知心的Sam哥，支持无限次语音一对一解决你遇到的难题。「另外后续我新写的所有对外的付费专栏，在星球内都是免费的，且可以拿到所有源代码。」

知识星球内后续将推出20+个付费专栏，覆盖电商全链路：

选购线	用户会员营销线	中后台
购物车服务	营销系统	订单系统
商品服务	用户系统	支付系统
菜单服务		结算服务

从前台选购到中后台结算，星球成员全部免费，后续新增也不额外收费。

我的知乎账号:

SamDeepThinking