2020年，我做了一个让很多人意外的决定：离开做了八年的技术岗位，去创业公司做运营。
当时朋友们都问我，好好的技术不做，为什么要”降级”？我当时的回答很官方：想看看技术之外的世界。但说实话，心里也是没底的。八年写代码的经历，让我习惯了用逻辑解决问题，习惯了深夜debug的孤独，也习惯了那种”技术解决一切”的傲慢。
三年后，我又回到了技术岗位。但这次回来，我对”什么是技术好”有了完全不同的答案。
离开之后，才发现技术不是全部#
刚离开技术岗的那半年，我经历了严重的”技术人戒断反应”。
运营工作需要频繁和人打交道：和用户聊天、和销售撕逼、和产品博弈。我一开始很不适应，总觉得这些事情效率太低——为什么不直接写个脚本自动处理？为什么要花一下午和用户聊需求，而不是直接给个解决方案？
直到有一次，我们的产品上线了一个功能，技术实现很完美，代码review也过了，但用户就是不买单。我花了三天时间和几十个用户聊天，才搞明白：我们解决的是一个”不存在的问题”。技术团队觉得这个功能很酷，但用户根本不需要。
这件事给了我很大的冲击。做技术的时候，我们习惯于”接到需求就开始做”，很少去质疑需求本身。我们觉得把代码写好、性能优化到位就是尽职了。但站在运营的角度看，如果方向错了，技术再好也是南辕北辙。
我开始理解，为什么有些技术很强的人做的产品会失败，而有些技术一般的人反而能做出用户喜欢的东西。因为技术只是工具，而不是目的。
技术外的经验，让我回到技术岗后更强#
2023年，我重新回到了技术岗位。不同的是，这次我不再只是”写代码的人”。
在运营岗的那三年，我学会了三件技术培训里没有教过的事：
第一是理解业务 。以前接到需求，我会问”具体要实现什么功能”。现在我会先问”为什么需要这个功能”、“这个问题有没有更简单的解决方式”。很多时候，真正的需求和技术方案之间有很大差距，问清楚能省下大量无用功。
第二是沟通成本 。以前我写的文档技术性很强，产品和运营经常看不懂。现在我会站在对方的角度，用他们能理解的语言解释技术方案。这不是”降低标准”，而是让技术真正能被业务团队用起来。
第三是优先级判断 。以前我觉得所有bug都要修，所有代码都要优化。现在我明白，有些技术债务可以先放一放，有些优化做了也白做。资源永远有限，关键是判断什么对业务价值最大。
这些能力让我的技术工作更有价值。不是代码写得更好了——说实话，三年没写代码，我的编程能力反而退步了——而是我知道该把有限的精力投在哪里。
重新定义”什么是技术好”#
以前我觉得，“技术好”意味着代码简洁、架构优雅、性能极致。这些当然重要，但现在的我会加几条新的标准：
- 能不能快速理解业务问题？
- 能不能和产品、运营有效沟通？
- 能不能判断什么是真正重要的？
- 能不能在有限资源下做出最优取舍？
说到底，技术是为业务服务的。如果一个技术方案代码写得再漂亮，但解决不了实际问题，那它就不是一个好的方案。
我见过太多技术团队陷入”过度设计”的陷阱：花了三个月搭建完美的微服务架构，结果用户只有几百个；或者纠结于代码风格统一，却忽略了核心功能的缺失。这些都是”技术视角的盲区”。
什么时候该离开技术岗？#
很多人问我，离开技术岗值得吗？我的答案是：看你想解决什么问题。
如果你只想做好技术本身，那深耕一个领域，成为专家，完全没问题。但如果你想解决更大的问题——比如如何让技术真正为业务创造价值，如何在公司里推动技术决策——那你需要跳出技术看技术。
离开的方式有很多种：转岗、创业、做技术管理、或者像我一样去尝试完全不同的岗位。关键不是去哪里，而是带着问题去体验，带着思考回来。
三年时间，我不后悔。因为我终于明白了一个道理：真正的技术高手，不是只懂技术的人，而是能把技术用到刀刃上的人。