最近迎来了一波“毕业季”，每天都有很多人写离职交接文档。
有几篇点赞数量颇高的文档进去看了下，除了正常的工作内容交接外，都有聊一些对自己负责的技术&产品的情感抒发,包括看法、思考、遗憾、期待等等。
突然有点悲凉，程序员之将“毕业”，其言也善？
程序员A资历较深，交接文档洋洋洒洒写了很多所负责系统正在进行或计划进行的 优化点。
文末总结了下：
很多优化点，如果针对性投入大量资源后不一定能马上看到“业绩”，所以除非“雷”真的快炸了，就让领导们决策吧。
我有一大堆想法，可惜无法实施。
嗯，略显悲凉了。
程序员是比较纯粹的。 程序员的视角中，稳定性、性能、成本、耦合等方面，都有太多可以去做技术优化的。
但是现实世界往往比较残酷，需要业绩增长、指标亮眼，技术优化项目如果无法带来直接的业务价值，往往会被排到后面。
我们常说的“屎山代码”，不是不知道有问题，不是不知道怎么优化，往往是因为“不值得”。
程序员B资历较浅，交接文档中除了正常工作交接外，还分析评价了加入公司以来参与的几次重大项目。
比较可惜，从他的总结来看，这几个项目都没有达成预期的业务目标。
文末总结了下：
xx业务是有潜力的，作为一个贯穿整个公司业务的一个实体，在整个数据流转中有很大的想象空间，可能只是还需要多一些耐心，找到更好的切入点吧。
程序员是比较无力的。 加班加点，努力在DDL前完成代码上线，但是决定项目成败的，却往往不是代码。
也许需求本身就不存在？也许项目价值本身就不明确？也许……
太多技术无关的因素会决定项目的成败，而项目的成败却会直接决定程序员的晋升与绩效，甚至去留。
所以，程序员该怎么办？
业务价值与个人价值结合
业务都没了，还要啥技术？这是很残酷的事实。
所以秉持业务价值导向的同时，想办法将个人价值与业务发展绑定在一起，在推进项目同时“夹带私货”。
小了说，在实战项目中锻炼自己的技术能力。比如可以尝试感兴趣的技术栈、实践一些设计模式理论、进行一些技术重构和优化等等。
往大了说，在项目过程中，锻炼自己的业务sense、项目推进能力、沟通协调能力。
如果业务做成了，个人和公司双赢。
如果业务失败了，那程序员也有自己的收获和成长。
选择大于努力，平台大于个人
写代码的同时，多看看周围的环境，多想想自己的下一站会在哪里？
也许 历史进程、个人运气 能决定一个人的上限，但是多一些思考，能一定程度上提高自己的下限吧。
往期热门笔记合集推荐：
原创：阿丸笔记（微信公众号：aone_note），欢迎 分享，转载请保留出处。
没有留言功能的悲伤，扫描下方二维码「加我」聊些有的没的吧～
本文分享自微信公众号 - 阿丸笔记（aone_note）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
