人美经典文章
我的第一份工作在一家小科技公司，岗位是后端开发。每天的任务很纯粹：把需求变成代码。我挺享受这种纯粹，甚至有点骄傲。当同事为需求变更焦头烂额时，我总能最快调整代码；当服务器出故障，我也能迅速定位问题。我觉得自己像个专治各种“不服”的技术高手。
直到那个周五下午，经理把我叫进会议室。
“下周三的客户演示，你来主讲吧。”
我愣住了。主讲？对着十几个陌生人讲两个小时？我的第一反应是找借口推掉——我负责把功能实现不就行了吗？
经理看穿了我的心思：“功能是你开发的，你最了解。总不能一直只跟电脑对话吧？”
那五天是我职业生涯里最煎熬的日子。我准备了五十页PPT，把每个技术细节都写得清清楚楚，还背下了每页要讲的内容。我觉得这跟写代码差不多——把要说的话预先编译好，到时执行就行。
演示当天，我站在会议室前面，看着下面坐着的客户代表。他们有的玩手机，有的交头接耳。我开始背诵准备好的内容，语速快得像在赶火车。讲到第十五分钟，一个中年男士打断了我：“能不能用简单的话说说，这个功能到底能解决我们什么问题？”
我卡壳了。脑子里全是技术术语，却拼不出一句普通人能听懂的话。最后是经理接过话头，用几个生动的比喻把价值说清楚了。我看着客户从茫然到恍然大悟的表情，第一次意识到：我把代码写完美了，却忘了为什么要写这些代码。
那次之后，我开始强迫自己走出舒适区。先是主动参加需求讨论会，不再像以前那样只等产品经理给最终文档。我发现，原来客户真正在意的不是技术多先进，而是能不能帮他们多赚钱、少操心。
慢慢地，我从只写代码，开始参与设计讨论。有一次，我花三天时间写了个“完美”的方案，自觉无懈可击。但在评审时，测试同事小声说：“这个流程，用户要点击七次才能完成目标，会不会太复杂了？”
我像被泼了盆冷水——我一直在为自己而设计，为展示技术而设计，却忘了谁才是真正使用产品的人。
改变是痛苦的。我开始主动找客服了解用户反馈，跟着销售去见客户，甚至硬着头皮在技术分享会上发言。每次尝试新东西，都像第一次学编程时那样笨拙。但奇妙的是，当我开始理解业务、理解用户、理解团队协作，我写的代码反而更有价值了。
真正的考验在今年春天来了。公司启动一个新项目，要在三个月内从零打造一款产品。这次，老板直接点名让我来负责——不只是技术，而是整个项目。
我失眠了三个晚上。负责技术我很有把握，但要带团队、控进度、跟各方沟通……这完全超出了我的能力圈。我想起刚工作时那个只会写代码的自己，突然明白：生活不会按你熟悉的领域出题。
那三个月，我学会了听弦外之音——当产品说“这个需求不急”，可能意味着他还没想清楚；我学会了把技术语言翻译成商业价值——不再说“采用了分布式架构”，而是说“系统能支持百万用户同时在线”；我学会了在冲突中寻找平衡——当设计和开发为排期争执不下时，组织他们一起找最优解。
项目上线的第二天凌晨，我在办公室看着数据报表，团队的其他成员已经回家休息。突然意识到，这一路走来，我最大的收获不是又掌握了什么新技术，而是终于明白：真正的成长，不是在自己擅长的领域深耕不止，而是敢于一次次走出舒适区，把“不会”变成“会”，把“不敢”变成“敢”。
现在的我依然写代码，但不再只写代码。我会在产品设计阶段提出用户体验的建议，在市场推广时提供技术角度的洞察，在团队管理中关注每个人的成长。我发现，当各种能力开始融合，它们产生的价值不是简单相加，而是相乘。
上周，一个新来的实习生问我：“学长，你觉得作为程序员，最重要的能力是什么？”
我想了想，没有说任何技术名词。
“是保持开放和勇敢——开放地去理解代码之外的世界，勇敢地去承担超出能力范围的责任。”
说完我自己都愣了一下。这完全不像几年前那个只相信ifelse的我会说的话。但这就是成长吧——从坚信单一技能可以走天下，到明白世界需要的是能连接各个点的立体的人。
这条路还很长，好在，我已经不怕迷路了。因为每一次迷路，都让我发现了新的风景。
未经允许不得转载：人美经典文章 » 内容均为网友投稿,不排除杜撰可能，仅可一观。
热门排行
阅读 (111)
1恋爱时的细心照顾，婚后的粗心忽略阅读 (105)
2想和他一起去海边散步看星星阅读 (100)
3明知没有结果 可心疼还在继续阅读 (98)
4曾共看的日落，成单人余晖阅读 (94)
5面包厂工人：给刚出炉的面包贴生产日期标签