快，是当下的工作主旋律。
拿到任务，快刀斩乱麻，达成目标交差。甚至同一时候处理多个事务。一天到晚忙前忙后。
一旦闲下来，便觉缺少了存在感。这未必是什么好事，事情做得比較浅，经验不能有效的积累。终于其实还是快不了。还反而让情绪受工作牵制。
相对于这样的做事做到恰到优点的做法，我更喜欢要做就往大了做。
从一个任务的表面来看，做出结果就算完事，这是结果导向。你要一份报告，我就给你一份报告。解一个Bug, 就保证这个Bug正常，扩展一下没有问题就好。假设真得非常紧急，这样做是理所当然。这时候慢下来就不合适了。但仅仅要有机会(能够向上沟通确认, 没时间就自己挤吧!)，就努力让自己慢下来，好好的从系统面。从总体思考一下，遇到一些细节时。都尝试去理解一下。也就是想想，除了解决这个问题，我自己能从当中得到什么提高， 产品能做什么改变。总之有机会就要尝试慢下来，让事情更具广度和深度，更具系统性。比方做一件事的时候，先分清轻重缓急，再理解任务的目标和目的。
比方遇到一个页面开发的问题，它足能够发散出非常多的维度。假设有时间。我就喜欢用例如以下的方式入手:
目标(Target)是解决特定问题。目的(Purpose):提高对产品及代码的理解。避免类似问题。提高产品质量。
1. 对于这个问题所属的功能，先总体了解这个功能中基本的类和流程。
2. 了解这个问题有没有标准规范，假设有就粗略的读一下，也了解一下相关概念的标准定义。
3. 别人是怎么做的?
比較一下类似产品的功能。写些測试页面验证一下。
4. 用户的期望是什么?
5. 从系统层面制订方案，而不是简单针对所要解决的问题。再发起讨论。
6. 怎样避免类似问题? 怎样验证问题？
7. 是否须要再深入理解? 有没有可能做些创新? 有没有申请专利的机会？
这也就是工作中尽量把事做大一点的思考方向，即使面对一个Bug, 也要发掘进一步优化创新的空间。
其实也仅仅有深入到细节，才更有机会发现优化和创新的机会，根本不须要依赖从一个高大上的项目中来提高自己。 由于技术工作不断的细化，以较小的学习小组的形式促进大家的学习提高会更加有效，较大规模的技术培训收益非常低。
再仔细一点，个人的学习却是最具成效的，可是这个习惯须要引导。
如今工作经验的价值已经远不如学习力的价值。关注于提高学习力远比关注于參于了什么项目有价值得多，工作中既要关注结果。也要关注过程和方法
