首先，其实除了极少公司或者每个公司的极少技术岗不需要懂太多复杂的业务，大部分程序员每天都会和很多的业务逻辑打交道。

只懂业务不懂技术，是产品经理。（没有丝毫鄙视的意味）

只懂技术不懂业务，永远不会成为骨干。（这里说的是 87% 的情况下）

在学校学习的各种理论知识，以及书本、资料上教的知识等等，其实只要静下心来学，都可以掌握很多的理论知识和所谓的技术。

而刚毕业的学霸级新人和资深工程师的区别，更多时候不是他们知道的理论和技术有多大差距，而是他们把理论和技术灵活运用到解决实际问题的能力，以及看到一些业务问题，能很快抽象成纯技术问题来思考的敏感度。

并发、竞争条件（Race condition），理论和技术都很成熟。但是实际业务中这里的坑依然是一个接一个。为什么？不是技术谁不懂，而是业务里有一些 特殊情况（corner case） 没有被考虑到。

代码怎么写性能好，怎么写性能不好，单纯的算法来比较，大家都能摸个门清。但是实际业务代码中还是有很多就是因为这样那样的低级错误而变得性能睇下。为什么？不是算法和实际复杂度谁不会分析，而是放在复杂的业务逻辑中，很多问题就变得雾里看花了。

那实际工作中怎么平衡呢？

无非两点：勤快愿动手、勤快愿动脑。

只有多动手，才能真正了解业务里的各种特殊情况（ corner case）。其实大部分时候，写出在 90% 情况下正确的业务代码可能需要 10% 的时间；而 90% 的时间或者说精力，其实是让那 10% 的各种意外和随机情况下业务逻辑也是正确的。不论是设计还是实现，如果你不知道那剩下的 10%，你就不能开发出好的系统。

只有多动脑去思考，才能写出更建固、稳定的业务代码。换句话说，那 10% 的 corner case，你用各种 if else，肯定也能写出来，但结果就是可扩展性极差，且代码极容易出问题。只有不断思考，不断抽象和归纳，才有可能真的用技术去解决业务问题。

即使是纯做底层的，比如说做数据库的吧。其实大部分时候，读写的优化还是和业务密不可分：网站的访问是比较平均的分布？还是每天每周有访问的高峰？读和写的比例大概是什么样？最常见的 Query 都是什么模式？需要注意哪些别的工程师可能写出的低效 Query？

记得我在职场初期花很多时间自发加班，干的最多的有两件事：

一是看相关项目的设计文档和代码，主要是主要是公司内部的。这一点我们算幸运，硅谷公司只要不是创业阶段，总有大量的好的开发模式和优秀代码可以参考。很多框架、模版，多看一看，慢慢就能掌握很多常用的技术和技巧。

二是修自己能修的bug，大部分是自己组里的，新的老的。修bug 是最能搞清业务逻辑的一个方式。而且当你很认真地做这件事的时候，大家都更愿意帮助你理解业务逻辑。你也就能更快地了解更多。

做必须的工作之外的事会比较辛苦，需要自己挤时间，而且一定要在把本职工作做好的前提下去做。做这些事的时候，不要想着回报和收获，做你自己觉得是对的事，剩的就顺其自然就好。不要觉得光做业务似乎和技术无关，其实技术只有解决实际问题才是真正的技术。不要觉得自己做的东西离业务太远，不够核心，一来公司里真有可有可无的东西，那早晚是要砍掉的，存在的，就是重要的，至少在存在的期间是重要的。而你处理事情的态度和结果，正是你最好的锻炼机会，也是给别人肯定你的机会。