“技术总是在短期内被高估，但是在长期又被低估。”
“技术总是在短期内被高估，但是在长期又被低估”
新年伊始，又要重新上路了，按理说，总结之类的都要年终之前就要做，可我偏偏是个懒惰的人，在洗澡的时候想起这回事，索性就写一写。2015年又是收获的一年，有展望有回首，感悟多少不敢说，也就以小见大，说说标题这句话。
这句话是之前所在公司CTO经常说的一句，不过他说是因为他作为一个技术合伙人与创始人经常做沟通的时候所得出的感悟非常印证这句话才说出来的，因为CTO在公司层面上以技术在给业务和运营做支撑的时候，往往是被后两者驱动，但是在公司技术演进的过程中是需要投入时间和占取资源的，实际的业务或者运营需求并不会给技术的演进太多的机会和时间，所以这句话就会随着时间的流转，公司的成长越发显得真实而贴切。
我既不是CTO也没什么太多的经验，理解这句话也许并不会从技术、产品、运营、业务与管理等等这些层面之上的高纬度去看待。作为一名开发者（比起技术人员或者是程序员我更喜欢这样称呼自己），窃以为：这句话的中的技术二字，很有现实意义。实际上包含两点意思。
- 开发者
- 某个具体的技术
实际上更多的场景中指的就是开发者，也许你会经常遇见这样的场景，往往某个公司开展某项业务之初，短期内为了满足这个需求，就需要某种开发者，比方说公司第一次做App，就要招iOS和Android的开发者，要做H5的移动端web站点，可能要找H5前端，而不会让已有的开发人员去学习，为什么呢？我不知道，也许能用人解决的问题尽可能用人解决，也许是国内管理层的黄金法则。话题扯回来，在这种情况下如若你目前擅长的技术是现在市场上奇缺的，那薪资待遇是很高的，你会是香饽饽，短期内，你就是爷，公司愿意用高薪资打开局面。
对于某种技术来说，就比较狭窄一点，比方说刚开始的时候我们要实现某个比较小型的业务，例如H5与移动端App要进行兼容，那么移动端H5站点的前端与App的前端能保持一致就非常能满足需要，那么hybrid app的技术就是当下需要考虑的，是用rect与rect native的组合套路还是angular js与js bridge配合的技术搭配，实际上是短期内比较有价值的探讨和实践。再比如，再做后端service的时候，提供灵活多变的接口，面临高I/O低计算的时候，Node可以对后端的基础service进行包装，扩展出平台服务层，而此时的Node可能也是短期内比较受重视的技术。
前面我们说了技术的两种含义，也提到了短期内高估的实际场景，我们再来几个长期被低估的例子
- 新兴技术的开发者刚进公司薪资杠杠的，但是技术老大不是做这个的，从此就再也没涨过薪资。（低估人才）
- 市场上现在比较缺这种开发者，但是过了一段时间，开发者多了起来，平均薪资就降了，长时间甚至会觉得这个技术的开发者也就是那么回事。（低估某种技术）
- 每当你使用的某个技术从刚开满足业务需求快速开发到后期开始梳理架构偿还技术债务的时候，业务、产品、运营与管理层往往都不怎么会给你时间，因为对他们来说，他们看不到明显的功能上或者是业务层面上的价值增加。但是代码的可读性、健壮性以及传承，架构能保证系统的稳定性与扩展能力，往往在业务、产品以及运营的方面看起来是理所应当的，这点成为深刻的矛盾点。（不过我个人认为，作为技术一方，可以从运营、产品以及业务层面考虑到某些问题，但反过来他们根本不能可能深入的从技术这方理解某些问题，比方说你能读懂产品需求、理解2/8原则、风口效应、口碑营销以及供应链压力等等意义，但是你跟产品、业务以及运营讲代码、讲架构、讲扩展性、讲核心逻辑，他们都懵逼了，毕竟难度不一样，而且他们觉得如果你讲，说明你只会技术性思维）
- 有些程序员学习某个当前迫切需要使用到的技术，一开始很用力很用心的学，投入大量时间与精力，但过了一段时间，自己认为这技术也就这么回事，进而不再继续深究，时间长了，你会发现这个开发者技术套路很多，但实际上某个技术领域的核心关键问题从来插不上嘴。（低估技术难度，所以标题这句话在开发者身上如是）
回头再来看看这句话，短期内被高估是因为在短期内的需求所迫，长期内被低估是因为技术的隐形需求要比实际上的业务务求多得多。这句话体现了技术在作为公司内一股核心力量的时候必须要解决的问题。
所感所想，作为开发者，首先不能功利化的、盲目地去投入自我的时间和精力到某个技术上，你需要考虑你将要投身的技术领域长期的隐形成本与试错成本。再者，投入到某个技术领域中其实不能走马观花，而要长期以往的进行深入研究与学习，才能获取更高的技术视野。最后，作为一个开发者，必然要深入业务、产品以及运营等其他层面协调处理问题（当然不是让你学会了这些跟他们去扯淡），真正的争取到技术在长期内的关注，尽可能的解决好隐形需求，集聚好量变形成质变的跬步，最终实现技术积累的爆发。
