《代码之外程序员重启人生》· 第01篇那些年程序员吃过的亏这一次全部重新来过。凌晨两点十七分。支付服务突然大面积超时。告警群里连续跳出十几条红色消息监控曲线像被人从中间折断成功率从99.98%一路掉到了61%。林川是被电话震醒的。电话那头项目经理只说了一句话“线上出问题了你赶紧看看。”林川翻身下床打开电脑连上公司VPN。查日志、定位版本、对比数据库、回滚服务、修复脏数据、补执行补偿任务。三个小时里他只喝了半杯凉水。凌晨五点四十三分最后一批异常订单处理完毕。监控曲线重新回到正常区间。群里终于安静下来。林川靠在椅背上看着屏幕右下角的时间眼睛发涩手指还停留在键盘上。他没有立刻睡觉。而是又花了四十分钟把事故原因、影响范围、修复步骤和后续方案整理成了一份文档。做完这些天已经亮了。早上九点公司召开事故复盘会。部门负责人坐在会议室最前面语气沉稳地说“昨晚系统出现了一次比较严重的波动。好在我第一时间组织协调各位同事配合得也比较及时最终没有造成更大的业务影响。”林川坐在角落里没有说话。负责人继续说道“这次也暴露出我们研发团队的主动性不够。很多问题不能总等着领导来协调。”会议室里没有人看向林川。仿佛昨晚查了三万多行日志、写了补偿脚本、一个人撑到天亮的人根本不存在。散会后项目经理走过来拍了拍他的肩膀。“辛苦了。”林川点了点头。项目经理又补了一句“不过你以后也要多从业务角度考虑不能只会解决技术问题。”林川愣了两秒。最后还是回了一句“好的。”这是他过去五年里说得最多的一句话。一、代码是他写的功劳却从来不是他的林川工作五年是团队里的后端骨干。哪个接口性能有问题找他。哪个服务半夜报警找他。新来的同事搞不定环境找他。产品临时改需求项目经理也找他。在所有人的评价里他都是一个“很好用的人”。但“很好用”并不是一个真正的褒义词。它更像是说这个人不会拒绝。这个人不会争。这个人出了问题一定会兜底。有一次团队接手一个交付周期只有三周的项目。正常情况下至少需要两个月。项目经理在会议上问“大家有没有信心”会议室里没人说话。林川看了一眼需求文档里面至少有十几个关键流程没有确认。他刚想提醒风险项目经理却看向他“林川技术上应该没什么大问题吧”所有人的目光都落在他身上。他沉默几秒说“加班的话应该可以。”那一刻他以为自己是在为团队负责。后来他才知道这句话相当于替所有人签了一份责任书。接下来的三周需求改了六次。接口文档变了四版。测试环境直到上线前三天才准备好。项目延期后复盘结论却写着研发前期评估不够充分任务拆解不够细致。那份结论经过所有人确认最终进入了林川的绩效材料。没有人提需求变更。没有人提环境延迟。也没有人提他连续两个周末没有休息。因为这些事只发生在聊天记录和口头沟通里。而那份正式的复盘文档里只留下了八个字研发评估不够充分。林川不是没觉得委屈。他只是始终相信领导心里应该清楚。公司不会亏待真正做事的人。直到年底绩效面谈。负责人翻着他的材料语气很客气“你的技术能力大家都认可。”林川听见这句话心里已经凉了一半。果然对方接着说“但你目前主要还是偏执行业务影响力不够跨部门协作能力也有提升空间。”林川问“这几个项目最难的部分基本都是我处理的。”负责人点了点头。“这一点我们知道。但你要明白做得多不等于影响力强。”“那什么才算影响力强”负责人想了想说“比如主动推动项目协调资源让团队看见你的价值。”林川没有继续问。他忽然发现这是一场无法通过事实取胜的讨论。他做过的事情对方未必真的知道。即使知道也可以用另一套标准重新解释。最后他拿到了B。而那个经常在项目群里发总结、在汇报会上负责展示、关键问题却总是找林川处理的同事拿到了A。对方晋升为技术负责人。林川继续负责核心开发。二、他一直以为代码不会骗人程序员对世界有一种朴素的信任。代码能跑就是能跑。接口超时就是超时。日志里发生过的事情不会因为谁声音大就改变。林川也一直这样理解职场。谁解决了问题谁就应该获得认可。谁承担了责任谁就应该获得机会。谁创造了价值谁就应该获得回报。可职场不是编译器。它不会在你写错的时候明确报错。它也不会在你写对的时候自动给出正确结果。很多时候你做的事情没有被记录就像从未发生。你提前发现的风险没有正式同步事故发生后就会变成“你为什么没有早点说”你默默帮同事解决的问题最后可能变成“这个项目是大家共同完成的。”你接受了一个边界模糊的任务最后所有未完成的部分都可能默认属于你的责任。代码世界里输入相同输出通常相同。职场不是。职场的输出还取决于谁定义问题、谁记录过程、谁解释结果。但那时的林川不懂。他只会低头把代码写好。他认为争取功劳是一件很难看的事。认为强调困难是在推卸责任。认为留下聊天记录是在防着同事。认为拒绝别人会影响团队关系。于是他一直选择那个看起来最体面的处理方式不说。不争。先把事情做完。然后他一次又一次成为那个最适合被忽略的人。三、绩效结果公布那天他趴在工位上睡着了那天晚上办公室只剩下林川一个人。灯已经关了一半。显示器上还开着事故复盘文档。文档最后一页写着后续加强研发主动意识提升业务责任感。林川盯着这句话看了很久。昨晚两点起床的是他。一个人处理事故的是他。早上写复盘材料的还是他。最后需要提升责任感的人也是他。他突然觉得很好笑。五年来他帮公司解决了无数问题。却从来没有认真解决过自己的问题。他打开招聘软件看了几分钟又关掉。不是因为不想走。而是他忽然发现即使换一家公司他也很可能继续变成同一个人。继续不拒绝。继续不留痕。继续相信做好事情自然会被看见。继续在每一次不公平发生后安慰自己算了。他太累了。趴在桌上不知不觉睡了过去。再次睁开眼时办公室的光线很亮。周围键盘声此起彼伏。林川抬起头看了一眼屏幕右下角。时间是三年前。他刚入职这家公司六个月。桌上的保温杯还是新的。显示器旁边放着一本刚买的《高性能MySQL》。他的手机震了一下。部门负责人发来消息小林这个需求比较急你今晚辛苦一下。后端做完以后顺便帮前端把接口联调也处理一下。林川看着这条消息整整一分钟没有动。他记得这一天。就是从这一天开始他第一次通宵加班。那次需求本来不属于他。前端接口之所以没有完成是因为负责人临时把前端同事调去支持另一个项目。上一世他没有问原因也没有确认优先级。只回了一个字好。那次之后团队里所有人都知道了林川愿意兜底。于是第二次、第三次、第四次越来越多的“顺便”落到了他头上。他从一个负责后端开发的程序员慢慢变成了团队里负责一切没人愿意处理的程序员。林川盯着那条消息突然笑了。他不知道自己为什么会回到三年前。也不知道这一切是不是一场梦。但他知道这一次自己不能再回复那个“好”字。他把手放在键盘上输入后端部分今晚可以完成。前端联调预计还需要半天如果同时处理订单模块优化会顺延一天。请确认一下两个任务的优先级我按最终优先级执行。他检查了一遍。没有抱怨。没有拒绝。没有情绪。只是把原本被隐藏的成本清清楚楚地摆到了桌面上。点击发送。三分钟后负责人回复订单优化先暂停今晚先保证这个需求。排期变更你在项目群里同步一下。林川没有像上一世那样私下接受。他打开项目群发送消息根据当前交付安排今晚优先完成临时需求及前端接口联调。原定订单模块优化任务顺延一天预计周四完成。相关安排已与负责人确认。消息发出去后群里很安静。前端同事过了一会儿私聊他说谢了兄弟今晚又得辛苦你了。上一世的林川会回复没事。这一世他回道联调我可以协助但前端代码还是由你负责修改。我这边主要配合接口问题排查。对方过了十几秒才回复行。林川靠在椅背上长长地呼出一口气。事情没有失控。领导也没有发火。同事更没有因此和他翻脸。原来拒绝承担不属于自己的全部责任并不会让世界崩塌。过去的他不是没有选择。只是他从来不敢选择。四、真正的重启不是换一门编程语言当天晚上林川还是加班了。但这一次他没有一个人包揽所有事情。前端同事负责修改页面逻辑。测试人员提前介入验证。产品经理确认了需求边界。林川只负责自己应该负责的部分以及必要的技术协助。十一点二十分功能联调完成。比上一世提前了将近四个小时。负责人在群里发了一句大家辛苦配合得不错。林川看着这句话没有期待里面出现自己的名字。他打开一份新的文档。文档标题只有四个字工作记录。他写下临时需求于今日下午加入原订单优化任务顺延一天。后端开发及接口调整由本人完成。前端修改由前端同事负责本人协助完成联调。当前功能已验证通过无遗留阻塞问题。写完后他保存了文档。这不是为了防谁。也不是为了抢功。只是为了确保当未来有人重新解释这段经历时他手里还有一份真实版本。程序员习惯给系统留下日志。因为没有日志就无法定位问题。可上一世的林川从来没有给自己的职场留下日志。他做了很多事。但那些事情像临时缓存一样项目结束后很快就被清空。这一次他决定不再让自己的价值只存在于别人模糊的记忆里。五、第二天第一次“甩锅”提前到来了第二天下午产品经理突然在群里问订单优化为什么延期了这不是原计划今天完成吗上一世林川看到这种问题通常会立刻紧张。然后用很长一段话解释前因后果。越解释越像推卸责任。这一次他只回复了两句话昨天下午增加了临时需求及前端联调任务经确认后调整了任务优先级。相关排期变更已于昨天下午在群里同步订单优化预计明天完成。随后他转发了昨天的群消息。没有情绪。没有指责。没有说“这不是我的问题”。但责任链条清清楚楚。产品经理很快回复看到了那按明天完成推进。对话就这样结束了。林川盯着屏幕有些恍惚。上一世同样的事情发生后他花了半个小时解释。后来项目周报里依然留下了一句研发任务延期一天。这一次只用了两句话问题就结束了。他终于明白很多职场冲突不是因为事情复杂。而是因为事实没有被提前固定。当事实只存在于你的记忆里它就可以被任何人重新定义。当事实出现在公开的文字记录里很多人就会突然变得讲道理。六、他修改的第一行代码是自己的边界下班前负责人从他工位旁经过。停下来问了一句“你最近表达比以前清楚了。”林川抬起头。“以前不清楚吗”负责人笑了笑。“以前就是让你做什么你都说好也不知道你手上到底有多少事情。”说完他便离开了。林川坐在原地很久没有动。上一世他一直以为领导把任务交给他是因为看重他的能力。现在回头看可能还有另一个原因交给他最省事。不用解释。不用协调。不用重新安排资源。只需要说一句“辛苦一下”他就会自己消化全部成本。这不完全是别人的恶意。有时候组织就像一个不断寻找最低阻力路径的系统。哪里没有边界任务就流向哪里。谁从不拒绝谁就会持续接收更多请求。谁习惯沉默谁就会被默认没有意见。过去五年林川把自己配置成了一个永远可用、从不报警、无需维护的公共服务。所有人都可以调用。没有权限控制。没有流量限制。没有异常提示。直到这个服务彻底崩溃。这一次他不准备再这样运行。他依然会认真写代码。依然会帮助同事。依然会在项目出现问题时承担责任。但帮助不再等于包办。负责不再等于背下所有结果。配合也不再等于放弃自己的边界。晚上七点林川关掉电脑。办公室里还有不少人。有人抬头看了他一眼似乎有些意外。毕竟上一世的这一天他加班到了凌晨三点。林川背起电脑包走向电梯。电梯门即将关闭时他回头看了一眼那排工位。他知道未来还有很多事情在等着他。那场让他背锅的需求评审。那个抢走他项目成果的同事。那次被忽视的架构风险。那场决定他绩效结果的汇报会。还有三年后凌晨两点十七分那次几乎让他彻底失望的线上事故。那些事情都还没有发生。或者说它们即将以另一种方式发生。电梯门缓缓关闭。林川第一次准时走出了公司。重启人生后他没有学习新的编程语言。没有获得顶级黑客系统。也没有突然成为公司的核心高管。他只是终于明白了一件事程序员修改系统之前会先确认问题边界。可很多程序员面对自己的人生时却从来没有定义过边界。而这一次他修改的第一行代码是自己。写在最后很多程序员不是能力不够。只是太习惯用解决技术问题的方式解决职场问题。发现漏洞就自己补。看到异常就自己修。别人没完成就顺手接过来。可职场不是一个等待你不断修复的开源项目。有些责任不说清楚就会默认属于你。有些价值不留下记录就会像从未发生。有些边界第一次不建立以后就会越来越难建立。林川的重启才刚刚开始。下一次他将回到那场改变自己绩效结果的需求评审会。上一世他替所有人承诺了三周上线。这一世他决定让每一个人都看见一个“不可能完成的排期”到底是谁决定的。本篇留一句话职场里最危险的从来不是能力不足而是所有人都知道你的边界可以被随时越过。