在小公司的程序员 前端不够你顶上，后端忙不过来你也得扛，Redis 没人管了领导说"你顺便看一下"，同事代码跑不通也来找你帮忙排查。一天下来感觉自己啥都干了一点，但回头一想，正经的业务代码好像也没写几行。
心里多少会有点不平衡：这些事又不是我份内的，我的时间全被占满了，我拿什么成长？
说实话，这个困惑自己之前也纠结了很久。后来经历了一些事情，想法才慢慢转变过来。
先说一个面试时经常遇到的场景
几乎每个跳槽的人在准备面试时都会抱怨上一家公司："我一直做业务 CRUD，没机会接触 Redis 集群，没封装过中间件，没做过性能调优。"
面试官问 Redis 持久化机制，只能背八股文。问线上 Redis 内存打满了怎么处理，一脸茫然------因为确实没碰过。
但你想想，如果你在小公司，领导让你管 Redis，这不就是一个现成的机会吗？你亲手装过、配过、调过，处理过内存爆掉、连接数打满、慢查询拖垮服务这些问题，你对 Redis 的理解就不再是背面试题那个层面了。
这些东西在大公司里可能是专职运维的活，你一个写业务代码的压根没有机会碰。反而是小公司这种"什么都要你干"的环境，逼着你把全链路都走了一遍。
杂活里面藏着什么
再说帮同事排查问题，看起来是耽误了你的时间，但本质上是在锻炼你的问题定位能力和对系统全局的理解。你能排查别人的代码问题，说明你对整个调用链路、数据流向、异常处理机制心里是有数的。这种能力在面试中体现为"你解决过什么复杂的线上问题"，在工作中体现为"出了棘手的事，大家第一个想到的是找你"。
帮运营导数据、帮测试搭环境，这些看起来更"杂"了，但你想想：导数据你得写 SQL，写得多了你对业务的表结构和数据关系比谁都熟；搭环境你得了解整个部署流程、中间件依赖、配置管理，这不就是 DevOps 的入门课吗？
所以换个角度看，与其说这些是杂活，不如说是一个免费的实战训练营。领导给你安排这些事，某种意义上也是信任你------他觉得你搞得定。
当然也不能无底线地接
话说回来，凡事都得有个度。如果你发现自己百分之八十的时间都在帮别人擦屁股，自己的核心业务完全推不动，那就得警惕了。
杂活占比不到三成的时候，正常范围，权当拓宽技能面。到了三到五成，就该找领导聊聊优先级了，适当调整一下。超过一半，你得认真想想：你是在被培养，还是单纯被当成免费劳动力使。
这里有一个判断标准：这些杂活有没有让你学到东西？ 每次帮别人解决问题，你都能积累一些新的认知，那就是值得的。但如果纯粹是重复性的体力劳动------比如每周手动帮运营导一次数据，那你应该做的是花两个小时写个脚本把它自动化掉，而不是每周老老实实手动干一遍。
还有一点很重要，主动把杂活变成自己的成果。 你帮同事排查了十次线上问题，别排完就算了。花点时间总结一下常见问题的分类，整理一份排查手册分享给团队。这样一来，杂活就变成了你的产出，绩效评估的时候也是实实在在的亮点。
说到学习，聊聊大多数人的真实状态
既然说到"杂活是学习机会"，就不得不聊怎么学习这件事，毕竟绝大多数搞技术的对技术还是有些追求的。
很多人觉得自己挺爱学习的。买了几本书放书架上，收藏了几十篇技术文章，关注了一堆技术公众号，偶尔刷一刷就觉得"嗯，今天又学到东西了"。但真要动手写的时候，啥也写不出来。
这不是学习，这是自我感动。
比这更常见的几种情况：
有意识没行动。 知道该学，但就是不动手。"等我忙完这个项目就学"------但这个"忙完"永远不会到来。项目一个接一个，你的学习计划永远排在后面。
没方向没目标。 今天觉得 Rust 酷想学，明天看 Go 火了又学 Go，后天觉得 AI 是趋势又去折腾 Python。什么都想学，什么都没学进去。一年下来感觉自己啥都会一点，但啥都拿不出手。
被动应付。 公司组织技术分享，或者领导要求学某个东西，心里第一反应就是"又搞形式主义，浪费时间"。带着抵触心理去听，听完啥也没记住，下次还是老样子。
过度依赖 AI，放弃思考。 这个问题在最近这两年尤其明显。遇到问题直接问 AI，AI 给答案，复制粘贴跑通了，觉得自己"会了"。但你跳过了最重要的环节------自己思考的过程。以前没有 AI 的时候，一个问题你可能要翻半天文档、查源码、试好几种方案，折腾一天才搞定。但正是这种折腾，让你对问题的理解深入骨髓。现在 AI 直接把终点端到你面前，你到了终点，但路上的风景一个都没看到。
真正会学习的人长什么样
观察了身边一些人之后，我发现那些技术成长快的人，有几个共同的特点。
沉得住气。 不是那种三天打鱼两天晒网的"自律"，而是能持续地、稳定地投入时间去钻研一个问题。今天看了一点觉得有意思，明天继续深入，后天动手验证，下周写个总结。不追求速成，但追求真正搞明白。
会总结和输出。 学了一个东西，不是"我知道了"就完了。他会用自己的话讲出来------写博客也好，做内部分享也好，跟同事讨论也好。只有当你能把一个东西给别人讲明白的时候，你才真正学会了。这不是什么高大上的理论，就是"费曼学习法"的本质。
会追问。 不是那种"这个怎么跑不起来"的表面问题，而是"这个技术为什么被设计成这样？它要解决什么问题？有没有更好的方案？为什么最终选了这种方案？"------这种追问本质的问题。每多问一层，理解就深一层。
你会发现一个有意思的规律：你知道得越多，问题就越多；问题越多，思考就越多；思考越多，你就越觉得自己知道的少。虽然有时候会让你觉得"我怎么啥都不会"，但这恰恰说明你在进步。
反过来，如果你学了一阵子觉得自己"啥都会了"，那大概率是停在了表面。
信息爆炸这个事，其实挺害人的
现在不是没有东西学，而是东西太多了。新技术层出不穷，公众号每天推送"2026 年你必须掌握的 XX 技术"，搞得人越学越焦虑，越学越浮躁。
AI 的出现又加重了这个问题。以前学一个东西，你要自己摸索、踩坑、查资料、试方案，虽然慢，但每一步都是扎扎实实的理解。现在 AI 直接把答案端到面前，省去了过程，也省去了思考。在我之前的文章**《当新人用了AI不再啃屎山代码，未来的高级工程师从哪来？》** 中也提到过AI带来的好处与成长过程中的一些挑战。
这就造成了一个分化：少部分人利用 AI 来加速自己的深度钻研------让 AI 帮忙查资料、整理信息、跑实验，但思考和判断的环节坚持自己做。而大部分人用 AI 替代了自己的思考，看似效率很高，实际能力原地踏步。
AI 是工具，不是大脑。 这句话值得反复提醒自己。
还有一个容易忽略的点：多走出去。 很多时候你觉得自己技术还行，是因为待在一个小圈子里。走出去跟不同的人交流，跟比自己厉害的人共事，才会发现自己的短板。你需要知道自己不知道什么，才能知道该学什么。闷头在小团队里干三年，可能还不如跟一个高水平的人聊三天收获大。
说几个我们团队里真实的事
管 Redis 的那个后端。 最初就是领导一句"你来看下Redis那个问题"，没加人也没加薪。开始确实烦，线上出过几次问题还背锅。但后来他慢慢把监控、告警、自动扩容都搭起来了，还写了一套运维手册。两年后跳槽，简历上"独立负责 Redis 集群的搭建和运维"这一条，直接帮他谈到了不错的涨幅。面试官追问内存淘汰策略、持久化机制、集群选举原理，他全都能结合实际场景讲得头头是道。这些东西，都是当初那些"杂活"给他的。
经常帮人排查问题的那个。 团队里有个人经常被叫去帮忙看各种疑难杂症，开始也觉得耽误自己的进度。后来他把每次排查的过程和结论都记了下来，慢慢积累了一份内部的故障排查知识库。后来有个技术经理的空缺，领导直接给了他------因为全团队只有他对整个系统最了解。
当然也有反面例子。 有个同学确实是来者不拒地接杂活，但从来不总结、不沉淀、不输出。三年过去，啥都干过一点，但啥都说不清楚。面试时人家问"你最擅长什么"，他想了想说"我什么都能干"。面试官要的是深度，他说的是广度。杂活干了三年，但没转化成自己的能力，这就是纯粹的消耗。
最后说几句
没有人会主动给你安排一个完美的成长路径。领导分的杂活可能不是最优解，但在你没法改变环境的时候，能做的就是从这些活里榨出最大的价值。
别抵触，杂活是免费的实战训练。但做完了一定要总结、要输出、要变成自己的东西。带着问题去学，追问本质，动手验证，别停留在"我知道了"。
等你能力到了那个份上，自然就有选择权了------到那时候，就不是领导安排你干啥你干啥，而是你决定自己要干什么了。
当然说这些并不是PUA大家，只是来个抛砖引玉，也是看到大咖的分享有感而发，单纯聊"杂活"太过于单调，本来是将"学习"方面单独再列一篇来讲，但这次索性聊到了就同时也聊些学习方面的事。
字码得比较多 在这快餐时代 估计一半的人会直接跳过不会细看，但还是希望能给一些同学一点启发也就有了点价值。