原来的那些问题去哪儿了呢？被少数造“”轮子的程序员们解决了——那些写操作系统、编译器、虚拟机、运行时环境、框架…等等的程序员们。这个趋势一直在持续——新兴的rust、golang等语言试图解决多核时代出现的并发问题，hadoop、spark、mesos试图屏蔽分布式系统底层的细节……可以预见，以后的并行编程和分布式编程门槛将会大大降低。这个过程是必然的，因为一项技术的发展，就是为了让更多的人能更方便的使用它。
而这些计算机工具不能直接应用于业务，因为计算机不能理解人类的语言，所以就有了大量的程度员存在，把人类的语言“翻译”成计算机语言。这些程序员是使用“轮子”的。当然这之间并不是非黑即白的，一个软件在多大程度上可以被称为轮子，取决于它的复用性。如果一段代码只能在一个地方使用，它显然不能称为轮子。而事实是，大部分为具体的业务逻辑所写的代码，复用程度很低。
对于把通用计算机工具应用到具体业务这个过程，中间到底有多少问题是技术性的？大部分技术困难被操作系统、编译器、虚拟机解决掉了，剩下的主要是大型软件（如果这是个大型软件）的复杂性控制——而这个问题又主要由少数高级别的架构师负责。对于写具体代码的程序员，剩下的技术性困难已经很少了。
举一个我供职过的公司，这是一家互联网公司，整个网站99%的代码是php，基本上没有java。没有专门的前端工程师，php、html和javascript代码混在一起。测试几乎等于没有，基本都是开发人员自测。上线流程只是个形式，质量控制部门唯二的作用就是向服务器上同步代码和出现事故之后给开发人员定责任。我曾经和另一个部门合作，他调用我提供的接口，而他在我的接口没上线的时候就上线了，导致一场事故。我本来是算法工程师，写php只是客串，而在这个过程中，没有任何上线依赖的控制，连提示也没有，甚至没有人对我进行上线流程的培训。然而，这是一家中等规模的互联网公司，己经发展了十来年，占据了所在细分市场领域的头号份额，并且己经上市。
我举这个例子并不是要黑它，而是想用事实支持上面的观点：大部分程序员，大部分所谓的“科技”公司，所面临的技术问题比想象的要少的多（这也许是那家公司没有CTO的原因）。
这不是个别情况，大多数公司都存在类似的问题——从技术角度看，它就是个渣，你会很奇怪它怎么还没死。然而事实是，它不但没死，反而活的生机勃勃，甚至上市了。公司的拥有者们早已实现了屌丝逆袭迎娶白富美的理想，而辱骂他们的程序员们还在苦苦的为房贷或者首付挣扎。这里面，有大量的非技术因素起着关键作用，尽管它们都自称科技公司。
越来越多的人意识到了技术的局限性。年初，一个同学找工作，他向来是个“纯技术流”的工程师，曾经写过很好的技术博客，甚至发起过开源项目。然而这次他说，“不想再做最底层的工程师了”，希望能做一些“高层的、能看到项目整体的”、以及“和人打交道，能够把自己的想法向外推动，并产生价值”的工作。于是，他去某公司负责带几个小弟去了。当我把这些转述给另一个同学的时候，他的反应是“我最近也有这样的想法”。还有个同学，说写了几年C++，技术上没学到多少，反而是接触的业务知识比较多。再比如我之前的leader，他是数学博士出身，曾经对算法有一种近乎天真的信仰；在我离职的时候，他已经完全转型为业务和产品导向了。而某个几年前就开始淡化技术，聚会时大讲“软实力”的同学，早已在BAT做了Team Leader，生活滋润，终日以跑步为乐。为何？其实原因很简单：公司里没有那么多技术问题需要解决。
《代码大全》里有个比喻，如果你的问题是给自己的爱犬造一个小窝，那么动手做就是了，如果出了什么错误，大不了重做一个，最多浪费一下午的时间。而造一个摩天大楼就不同了。所以，如果写一份“狗窝”级别的程序，算法、数据结构、设计模式这些又有多大意义呢？甚至违反了DRY原则也没关系，反正一段代码也拷贝不了几次，出了bug就改，大不了重写一次，最多浪费一下午。而且，说不定这个项目两周之后就被砍掉了。如果你做的是一份“造狗窝”的工作，就算你有造摩天大楼的技术，和屠龙之技又有什么分别呢？唯一的“好处”就是你会据此向老板提出更多的加薪要求，以至于老板对你“另眼相看”。