以下是字节跳动研发 Jacky 的自述——
刚到字节那段时间，我的代码被产品经理打回来八次。
不是写得不好。功能都能跑，测试也全绿。但产品说："你做的跟我说的不一样。"
我回去翻了 PRD，一字一句对着看，发现文档只写了"用户想要什么"，没写"为什么用户想要这个"。我写的代码只是实现了功能——但产品想要的，是一个理解用户为什么点这个按钮的开发。
那天晚上我坐在工位上想了很久。然后做了个决定：以后每次接需求，先不问技术方案，先问三个问题。
这个功能到底是干嘛的
现在字节内部有个现象：纯写代码的研发，越来越难往上走了。不是编码能力不行，是你跟业务之间的那堵墙，正在慢慢把你圈死在"实现者"这个角色里。
我去年做了一个数据看板的需求。PM 给的原型很简单——几个图表，几个筛选器。正常操作是估时、开工、提测、上线。
但我多问了一句："这个看板最终是谁看？他们看完要做什么决策？"
PM 愣了五秒钟，然后说："其实我也没想清楚，要不我们一起梳理一下？"
后面三天，我们拉着运营同学开了四轮会。需求从"做一个看板"变成了"做一套决策辅助系统"。最后上线的版本，PM 在全员会上说"这是今年最成功的产研协作案例"。
不是做了什么技术选型有多牛逼。是我跳出了代码，站在了业务那头在想问题。
平台大了，焦虑也大了
来字节之前我在一家中型公司。那时候我的代码质量在组里算好的，review 很少被打回。来了字节之后，我突然发现自己变成了一个"普通程序员"。
不是退步了——是参照系变了。以前你比较的是周围十几个人，现在你比较的是几万个跟你一样甚至比你强的人。有人比你年轻，有人写代码比你快两倍，有人凌晨三点还在群里回消息。
你不焦虑才怪。刚到字节那段时间我每天晚上睡不着，满脑子想的是：我是不是不够好？我是不是选错赛道了？
后来想通了一个道理：平台变大不自动带来松弛，你只是换了一个竞技场。以前你打村口篮球赛觉得自己还行，现在进了职业联赛，突然发现连替补席都难坐。但这不是坏事——因为焦虑本身不是问题，问题是你有没有因为焦虑，开始做不一样的事。
不会经营关系，就用做事建立位置
我不是那种很会跟领导吃饭的人。团建能不去就不去，茶水间的闲聊也不太主动。以前觉得这是个短板，现在不这么想了。
你可以不会混圈子，但你必须让圈子需要你。
我做的事情很简单：每周写一份技术分享文档，丢到组里公开的飞书群里。内容不是那种"某个中间件原理分析"的大文章，就是这周做需求遇到的坑、踩过的雷、学到的东西。还有我发现的一个规律：某个业务指标最近掉得厉害，我看了日志，根因可能在某个接口的超时配置上。
这种文档一开始没人看。写到第八周的时候，leader 在周会上单独提了这件事，说"大家可以看看，很有参考价值"。到了三个月后，隔壁组的 PM 直接私聊我，问我能不能帮他们看一下某个数据异常。
靠做事建立的位置，比靠吃饭建立的更稳。不会立刻带来热闹人气，但会慢慢积累信任——而且这种信任一旦建立起来，很难被替代。
真正拉开差距的，不是代码能力
在字节待了一年多，我观察到一个很有意思的事：那些晋升最快的研发，不一定代码写得最好，但他们都做对了一件事——能用业务的语言解释技术。
比如你跟老板说："我优化了 Redis 缓存策略，把 QPS 从 5000 提升到了 12000。"老板可能会点头。
但如果你说："因为加载速度变快了两秒，上周客户端的次日留存涨了 0.3%。"老板的眼睛会亮。
同样一件事，换一种说法，决策者接收到的信号完全不同。不是因为老板不懂技术，是因为老板需要做决策。而决策需要的是：投入多少人、产出多少价值、影响哪些指标。你给他技术指标，他还要自己翻译一遍；你给他业务指标，他直接就能拍板。
谁能帮决策者省掉翻译这一步，谁就更值钱。
写完代码只是一个开始
我现在带新人，跟他说得最多的一句话："代码跑通不是终点，上线也不一定是。"
你做了一个功能，如果没人用、数据没变化、业务没感知，这个功能就只是你工时的消耗。你真正需要关心的是三个问题：
- 用户用没用？
- 数据变没变？
- 业务有没有因为你的代码变得更好？
这三个问题答不上来，你写的代码再好，也只是在完成工作，而不是在创造价值。
有一天我突然意识到一件事：我干的活越来越不像一个程序员了。我要去理解用户的"待完成任务"是什么，我要去判断这个需求值不值得做，我要去看上线后数据怎么变化。这些事以前都是产品经理和运营在做，但现在我自己主动去做了。
不是因为我被要求这样做，是因为我发现：当你开始用业务的视角写代码，你对"这个需求到底有没有意义"的判断力，会远远超过那些只看 PRD 的人。
而这种判断力，才是你从"普通研发"变成"不可替代的人"的核心。
最后说一句
如果你也在大厂，也在焦虑，想跟你说三句话：
第一，焦虑是因为你站在了一群更强的人中间。这不是坏事。
第二，不会社交没关系。用文档、工具、分析、分享，慢慢让所有人知道你是谁。
第三，早点开始用业务视角写代码——不是为了讨好产品经理，是为了让自己从一个"写代码的人"，变成"能独立判断价值的人"。
那个才是真正拉开差距的东西。不是技术，是你理解业务的程度。