【无标题】

通常就两条：接难一点的任务，找比你强的人聊。

很多人觉得提升就是多花时间：多加班、多接几个简单需求、年复一年做差不多的事。时间花上去了，能力不一定跟着涨。

天天改表单、加字段，和从零重构一个复杂模块并把它上线，完全是两回事。大部分时候前者只是在写代码；后者你要自己理清需求、写技术方案、过评审、实现、上线，中间还要跟测试、产品、运维打交道。写代码、做设计、推进事情、出了问题自己负责，这些是几件不同的事，只能在一件真正难的任务里一起练。

简单任务通常只用得上其中一块：产品说加两个字段，你改一下接口、自测、上线，就算做完了。很少逼你去想数据量大了怎么办，老模块和新模块怎么切，上线失败了怎么回滚。

难的任务有业务后果，方案要给人看。上线后有没有出问题，从监控和业务数据上能直接看出来。难的任务会把需求分析、架构设计、方案评审、编码实现、上线推进捆在一起，很难拆开单独练。

做难的任务

举个例子。从0到1重构一个复杂模块，最后要交付上线。不是改几个接口就完事，模块本身技术复杂度就高，老代码耦合重，还要保证业务不能停。

你要自己做需求分析，跟产品把边界谈清楚。写技术架构方案，说明怎么拆、怎么切流量、出了问题怎么回滚。方案拿去评审，被同事指出问题，改一版再过。然后才是写代码、联调、上线。

上线那几天往往也不顺。可能第一次上线失败，要连夜查原因。测试人手不够，你要去协调排期、帮测试理清重点用例。下游系统对接口变更不知情，还要你跑去对齐。这些事指望不上别人，得你自己往前推。

做完这样一件事，需求怎么拆、方案怎么写、代码怎么实现、上线出了问题怎么处理，都比天天改表加字段时更熟练。

难的任务从哪来？主管愿意交给你，一般是因为简单的事你已经做完整了。需求先搞明白再动手，该测的测了，按时交，出问题能跟、能修。信任有了，重构、疑难排查、跨团队改造才会分到你这里。

不用等环境完美，先把交给你的事做到有头有尾。

只做简单任务，很多能力只是偶尔用一下，做完就忘。因为没在一件完整的事里用过。

难的任务能逼你长本事，但有一个坑：盲区。你自己不知道的问题，查资料也搜不到合适的词。方案里漏了回滚步骤、漏了和下游的兼容，往往要别人点出来。光靠一个人负责不够，所以要找比你强的人聊。

找高手聊

别指望团队里人人都有那种传说中的大牛，但通常会有比你水平高的人。找他们，最好是带着问题去请教或探讨，而不是指望对方天天给你单独辅导。

比如你在做模块重构，资深同事过方案时问一句：切流量按什么比例切，失败了怎么回滚，老接口和新接口并存期间数据怎么保持一致。这种具体问题，比你自己关起门想三天更有用。

有些人成长最快的那段时间，不是加班最多，而是有高手在代码评审里给了很多具体意见。跟高手一起解决一件真正的难题，比单纯堆时间有效。

高手不一定是名人。团队里总有一两个明显强的人：方案想得细，排查有条理，能问到关键点上。

关键是对方愿不愿意在你把来龙去脉说清楚之后，花二十分钟跟你过一遍。

怎么聊才有用？别空问如何提高。要把问题问具体，事先自己试过、查过，带着背景和卡点去。

比如这样说：我在重构订单模块，方案是双写再切流量，评审时有人质疑回滚路径，我改了一版还是不确定并发写入会不会丢数据。对方才能帮上忙。

一次聊一个点，比泛泛地求建议有用。可以是代码评审、方案评审、吃饭时聊二十分钟、语音对一下。你把情况说清楚，对方追问、指出问题、给几个选项。

聊完要有后续：改一版方案、试一种写法、记下几条下次要检查的点。不然很容易听完就忘。

身边暂时没有高手，也可以在团队里找愿意帮你看关键代码的人，哪怕只找一个人。不用等认识什么大牛才开始。

两件事可以同时做。接难的任务时，你更知道该问什么。跟高手聊完，也更容易敢接下一件难的任务。

只做简单任务，很多能力练不到。只做任务不请教，同样的坑会反复踩。进步快的人，往往两样都有：手里有一件正在啃的难任务，身边有一两个能具体指出问题的人。

小结

有人一直在简单需求里磨了很多年，也有人独立扛过一两轮模块重构上线之后，明显能独当一面。

难的任务，把需求、设计、编码、协调、上线放在同一件事里做，这是本事增长最快的路子。找高手聊，是少踩坑、少走弯路。

你回想最近一次明显变强，是因为接了一件以前不敢接的任务，还是因为某个人帮你点破了一个具体问题？往往能对上其中一条。

先从手头一件事开始：要么把它按上线标准做到位，要么带着一个具体卡点，找一个人聊二十分钟。