无论业务代码、技术代码，本身都是技术活。
通常所说的“业务代码”负责实现用户的业务功能，主要与用户、系统的功能需求有关，对应于软件架构业务逻辑（Business Logic）或领域（Domain）逻辑层的代码，类似于 MVC 模式里的 Model。而“技术代码”大概是指那些与业务功能无直接关系而常与系统的非功能需求有关的架构级代码，例如各种开发平台、框架、中间件中处理网络通信、数据存储、多线程管理、语言处理等等技术架构、基础设施方面的低层或底层代码。
可是，上层或应用层的业务代码就一定没技术含量吗？不一定。产品组、业务组的代码叫业务代码，平台组、架构组的代码叫技术代码，所以业务代码就一定没技术、没难度、没意思？这认识上恐怕有点误区，业务代码难不难、值不值得你投入取决于你的行业、业务领域本身的问题复杂度，其实许多行业领域的业务代码也是很有难度、值得钻研的。
我理解题主大概更想说的是：老是重复干没啥意思的工作，编写自己早已掌握了的、低难度、低技术含量的代码（这些不一定都是业务代码）是浪费时间，耽误了个人成长的机会。这点我基本同意。
如果你的业务代码大多是简单的 CRUD，确实可以考虑挪位子了。
拜师学艺
要想成为技术大牛，绝非一件易事，所以完全不必也不应焦躁。
具体办法很多，说一个在公司里最简单直接、快速有效的办法（上策、捷径）：
拜你团队里的技术大牛（比如架构师，或其它技术明显超过你的同事、Coach、Mentor 等等）为师，让他们平时能经常指导你（开小灶），给你分配一些有技术难度的任务做，有计划、有步骤地提高。（能否做到，看你的人缘了）
在实际工作中有高人指点、带领必然可以少走许多弯路，这比你平时利用业余时间通过自学、啃书、报培训班等等来提升，要高效得多。问题是，码农大多加班还不来及、忙不过来，能有多少业余时间呢？所以，最好是就从日常工作中获得提高，而不是另找其他时间。
如果架构师、团队领导安排你写“技术代码”、做一些更有难度的工作，自然你就可以名正言顺地通过日常工作来提升自己的技术了，这是一举两得。
总结一句话：只有你自己牛逼了，机会才会到你头上！业务代码都写不好肯定成为不了大牛，但是能写好业务代码只走了成为技术大牛的第一步！
