快是一种优势
有的人认为，慢工出细活。有的人则说，天下武功，唯快不破，快才是硬道理。放在软件开发中，以及自我学习成长中，我觉得后者跟合适一些。快，能成为一种优势。
学生时候学过一个词叫认真，我是很秉承这一点的。但是，还有更重要的有意义的另外一个词叫效率。什么叫效率？说白了，就是找对一个做起来比别人轻松比别人快的方法。
拿一个bug fix来讲，测试已经给你提单了，问题也是必现的。只不过呢，问题单里所描述的方法来复现问题就是需要四十分钟。好吧，我编译这么大的一个工程，怎么也需要个四五分钟，修改代码需要个几分钟，问题复现了分析分析也需要个把分钟。这么多的时间，你是否真的没多想，撸起袖子就开干了呢？如果是这样，反复修改验证的时间最少也可能是一天的，甚者更多了。明显这种慢腾腾的方式，作为一个想要成为优秀程序员的我们来讲，肯定是没有办法接受的。让它快起来吧！
这其中，可能最无法直接改进的就是分析现场和修改代码了。然而，代码编译是一个可以加快的过程，只不过它不适合放在这个时候来做，这需要对make文件进行依赖改进的，可以放在后面的时候进行慢慢优化。在这个阶段，最适合改进的，就是问题的复现了。最好把问题的复现拆成好几个阶段或者步子，把固定不需要反复的步子抽出去， 将问题真正出现的那部分抽出来、最小化它，然后再反复地猜测、验证。大多数的问题其实前提条件的搭建是比较耗时的，问题出现的过程一般不会太长的。我在最近的一个问题解决过程中，集群搭建使用了半个小时，问题的复现过程却只有5分钟左右（这还是因为我比较懒，没有把那个必现的用例再简化，而是直接提过来用了，要不复现时间还可以再短的）。这就是快，就凭着这几点，我就可以比别人少出一部分时间来，可以去做更多的事情。这就是快，就是一个优势。
其实，还有一个部分是成长过程中的自我学习。这里的快，同样不是一昧地快，而是一种讲究策略的学习方法了。有的人看书很快，有的人看书比较慢； 当前我就属于那个学习较慢的人。发现，这种方式有个毛病，就是看书慢、学习慢，学习的反馈也是慢的，导致其实学习的进展慢，自己的成长也是比较慢的。细细想过的，其实可以换个方式，就是先保证快速地看一次，然后细细想段时间，然后再看一次，不过这一次要关注不理解的点。之后，再找时间看一次， 再一次； 等到确实看明白之后，就不再是用眼睛来看书了，应该把书合上，把所看、所学、所知在心里过一次，沉在心里。
身边有一些优秀的人，他们吸收知识很快，理解东西也很快的，对于陌生的领域进入地很快； 这令我是比较羡慕的，也一直在向这些优秀的人看齐。所以，应该在学习的方法、理解的思维上以及知识的系统上来下功夫。我比较相信一句话是：