一个技术总监的忠告：精通那么多技术，你为何还是受不到重用？( 二 ) _技术

其实这个观念其实是很有问题的。
对这些所谓“屎山”的代码，你如果全都读进去，研究下去，你起码会有两个好处:

你能具体知道代码烂在什么地方，那么以后你的代码就不会出现同样的问题——由于你知道了烂代码烂在哪里，你一定能写出更好的代码，从而让那些屎山的代码逐渐会被自己写的好代码所替代。这样一比较，你的专业能力会显得非常突出，让更多的人认可你这位架构师的能力。
你对公司这些代码读的越多，掌握的越多，你越不可替代——对公司这些代码读的越通透，你越能更快速轻松地把控这些代码，让以后对这些代码的变革变得更容易。而轻松修改、革新这些代码的能力，就会变成你在这家公司不可替代性的重要因素。

所以，各种代码，无论质量好坏，都需要能读懂读通，并且读的越多越好。
能读懂读通任何质量的代码，才是真正的掌握了阅读代码的能力。读的越多，则能识别代码质量的能力就越强，将来自己就越能写出更好质量的代码。
2. 能准确判断项目的发展方向大刘和老田谈的时候，让大刘印象最深刻的就是，老田对项目发展状态的精准判断。
三年前，俩人一起搞了个供公司所有业务项目用的监控系统，目的是解决公司项目错误无法及时发现和处理的问题。
当时，这套监控系统公司要的急，大家匆匆设计了一版，就赶紧赶鸭子上架的做了一版。
技术方案也没花太多心思，怎么快怎么来。搞完之后，大刘觉得这项目以后也就这样了，公司内部项目，既没有发展，也没有什么前景。
可是，如今和老田沟通后，大刘才吃惊的发现，老田居然一直跟着这个项目，并对这项目进行了无数次总结分析和优化。
随着不断地改进，这套项目竟然发展出来了一套非常完备的 APM 系统，使用体验非常不错。公司的商务给客户出解决方案的时候，经常也会连带着把这套监控系统包含到解决方案里。客户的反馈也很好，为公司拿下了更多的订单。
而大刘自己呢，为公司的核心系统设计了一套底层的服务调度编排框架，公司很多系统的底层都依赖于这套框架。
虽然这套框架大刘自己认为写的很棒，但是由于部署复杂，对应的一些辅助工具链也由于大刘的忽视，没有及时开发出来。导致后续的新项目，大家宁肯用一些开源框架自己改进，也不再使用大刘的这套框架。
分析起来，其实这也算是大刘和老田对各自项目的发展判断能力的差距导致的。
老田根据用户反馈和市场行情，他感觉监控系统本身应该是有前途的。并在调研了市面上竞对产品的基础上，让这套监控系统迸发出来了绚烂的色彩。
而大刘，高开低走，写出来一个好框架，但是由于对框架的预期判断错误，加上对用户反馈重视不够，最终导致本来应该非常出彩的框架就此沉沦了下去。
3. 去主动管理会议作为公司比较重要的技术专家，大量的会议是免不了的。
大刘对此非常烦恼，经常因为这些冗长的会议，耽误了许多手头的工作。
特别是，大刘作为架构师，需要大块连续的时间去思考技术难题，解决系统问题，以及考虑新项目的架构设计。但是频繁的会议，把大刘的时间搅和的支离破碎。
对于这个问题，大刘在饭桌上请教了老田。老田说，他也面对了这些问题，好在他通过一些自己的方法，很大程度缓解了这些问题。
老田做了如下几个事情: