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

知乎上有人问程序员如何接受工作内容毫无意义他举了一堆例子。按钮文案从「氛围」改成「空间」又改回来。一个按钮被疯狂点击后偶尔闪烁测试提了bug但觉得用户根本不会这么操作。git提交信息格式不对被打回。周报提交了领导根本不看。这些抱怨我见过太多了。每次看到反应都一样觉得工作没意义的人十有八九不是工作本身没意义是他还没走到能接触有意义工作的阶段。你觉得没意义的事可能是你没看懂先说按钮被疯狂点击这个。提问者觉得「用户根本不会那样操作」这个判断本身就暴露了经验不足。线上环境跟本地开发完全不是一回事。接口响应时间正常的时候用户确实不会连续点。问题在于接口不可能永远正常。数据库慢查询、网络抖动、第三方服务超时任何一个环节出状况响应时间就会从几百毫秒变成几秒甚至十几秒。用户看到页面没反应本能反应就是再点一下再点一下。俗称【一阳指】。这种问题的解法分两层前端加防抖后端做幂等缺一不可。前端的防护随时可以被绕过比如用户刷新页面重新点击后端的幂等才是兜底。前端的处理// 用户点击后立即禁用按钮等接口返回后再恢复 button.disabled true; try { await submitOrder(params); } finally { button.disabled false; }后端的幂等处理常见做法是用唯一请求令牌。前端进入页面时先请求一个令牌提交时带上后端用这个令牌做去重。同一个令牌只处理一次后续重复请求直接返回第一次的处理结果。这件事的关键不在于技术方案多复杂而在于你有没有意识到这是一个需要处理的场景。提问者觉得「用户不会这么操作」恰恰说明他还没经历过线上事故不知道用户在异常情况下的行为是不可预测的。再说git提交信息格式。有人觉得这是形式主义提交信息写个「fix」「update」也能跑何必在格式上较真。这种想法在本地开发的时候确实看不出问题因为你只管自己那一亩三分地用不着翻提交记录。但是如果是leader的话他是会看的就比如我我是看的。另外到了线上出故障了我也是会去看团队的人提交了啥功能的。一条好的commit信息长这样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