这8年码农路上我至少浪费了5年时间，这5年可以足够让自己成长为一个优秀的程序员，可惜我错过了，我用这五年时间和很多程序员一样在困惑和迷茫中找不到出路！
路上本没有坑,走的人多了,路就烂了。
在大公司做事情有一个特征，你只需要在工作时间做好公司给你安排的那份工作，你就会做的很好，这也就是说每个人都是一颗螺丝钉。所以，我在一进入大公司后，由于自己经历不够，再加上刚毕业就作为大学班上进入大公司的佼佼者，所以有点飘，不能沉下心来研究技术，所以浪费了一段时间。
虽然自己经常和周围的朋友进行程序生涯的交流，唯独这次交流才真正影响了我的程序人生。回想起来，影响程序员明天困局的往往就是一直挂着我们嘴边的小事，那些源码啊，框架啊，实战，造轮子，开源这一切都需要我们实实在在亲力亲为的一行行代码去解决。
我一直担惊受怕，过去，可能是因为我年轻，但现在，我已经不是那么年轻了，我仍然发现有很多事情让我害怕。
当年纪越来越大后，我开始变得不能加班。我开始用更多的时间和家人在一起，而不是坐在计算机前(尽管这样，她们仍是抱怨)。我在本地教育委员会社区里提供一些帮助，还组织开源兴趣小组参加活动。
现在的技术的学习曲线的增加，让我的忍耐性越来越低。各种新技术，因为新奇让人兴奋，但最终变成一场场争论。我越来越无法忍受这些充满市场宣传气息的喧嚣。我对技术看重的是稳定，清晰。
中国Java程序员的数量已经超过了100万，Java程序员面临的竞争压力越来越大，作为一名Java程序员，怎样努力才能快速成长为一名高级的程序员或者架构师，或者说一名优秀的高级工程师或架构师应该有怎样的技术知识体系，这不仅是一个刚刚踏入职场的初级程序员，也是工作三五年之后开始迷茫的老程序员，都必须要面对和想明白的问题。针对这些问题我总结出了一些经验！
阅读源码
程序员每天都和代码打交道。经过数年的基础教育和职业培训，大部分程序员都会「写」代码，或者至少会抄代码和改代码。但是，会读代码的并不在多数，会读代码又真正读懂一些大项目的源码的，少之又少。这也造成了很多错误看源码的方式。
分布式架构
随着我们的业务量越来越大和越重要，单体的架构模式已经无法对应大规模的应用场景，而且系统中决不能存在单点故障导致整体不可用，所以只有垂直或是水平拆分业务系统，使其形成一个分布式的架构，利用分布式架构来冗余系统消除单点的故障，从而提高整个系统的可用性。同时分布式系统的模块重用度更高，速度更快，扩展性更高是大型的项目必不可少的环节。
微服务
关于微服务架构的取舍
在合适的项目，合适的团队，采用微服务架构收益会大于成本。
微服务架构有很多吸引人的地方，但在拥抱微服务之前，也需要认清它所带来的挑战。
需要避免为了“微服务”而“微服务”。
微服务架构引入策略 – 对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。
性能调优
我们不仅仅对项目要运筹帷幄，还要能解决一切性能问题。只有深入学习JVM底层原理，Mysql底层优化以及Tomcat调优，才能达到知其然，知其所以然的效果。除了性能优化之外，也能提供通用的常见思路以及方案选型的考虑点，帮助大家培养在方案选型时的意识、思维以及做各种权衡的能力。
开发工具工程化
通过一小段描述信息来管理项目的构建，报告和文档的软件项目管理工具。程序员的战斗，往往不是一个人的战斗，我们如何在一个平台下高效的去重，进行代码review，对功能进行调整，debug，做到在统一的规划下步步为营，混乱的堆代码的过程中找到自己的记录。这一切都依赖于有效的工具。
项目实战
要想立足于互联网公司，且能在互联网浪潮中不被淹没，对于项目的开发实战演练是不必可少的技能，也是对自身能力的一个衡量，有多少的量对等于获得多少的回报。看似简单的一个项目需求图谱，其中的底层原理，实现原理又能知道多少？你搭建一个完整的B2C项目平台到底需要多少知识？这一切都是需要我们考量的。
并发编程
主要培养编程者深入了解最底层的运作原理，加强编程者逻辑思维，这样才能写出高效、安全、可靠的多线程并发程序。