过去两周，参加了校招新员工培训。学到了很多东西。
特别是上周，连续几天加班到9点10点去做项目，不过结果还错，我们team获得了Best UI和Best Presentation两个奖哈哈。
下面总结了一些新的体会：
数据库操作非常慢，耗时长，应该尽可能去优化。
比如，
所有的查询都有时间参数，那么用时间建立索引，以节约查询的时间。
经过测试，发现提交一次查询很慢，查询的结果集大小几乎没有影响，改进是大量减少查询次数。方法很重要，值得花时间去实现更快的方法。（当然，要权衡寻找新方法所花的时间和新方法所能节省的时间）
比如，
将分析完的数据从HDFS导入SQL Database。花了近2个小时找了更快的方式，节约的时间远远超出2小时。
更重要的是，周四晚发现一个bug，如果没有更好的方法，那么到周五很可能不能导出所有的数据。
如果新方法是替代手动操作，就更有必要了。任务的分拆数量等于独立模块的数量。
也就是说，一个人负责一个独立的模块。如果两个人在一个独立的模块，效率的提高很有限。所谓的人月神话。
手术室模型在我们团队也很适用，一个人主力去解决一个问题，其他人为他提供支持，做一些外围工作。不到最后时刻，不言弃。
我们到了周五中午，还没有做好search功能，大家协作努力，最后还是发布了search功能。同时还fix了几个bug。多个原型问题。
周五和hoyle商量ppt的时候，告诉他我们的Plan A还没有完全ready，不过有Plan B和C。
但是hoyle的回答很不一样，说他刚入职的时候也会像我们这样，但是现在不会了。原因是太多手准备说明我们时间安排的不合理。
关于这个问题，求解释。技术的重要性
技术重要吗？很重要，但是没有我想象的那么重要（相比培训前）。
写代码本身是很简单的事情，几乎处于整个项目最不重要的地位。
更重要的是利用相关的资源达成自己目的，如何去得到并运用资源很重要。
解决一个问题，技术本身不具备不可替代性，很多不同的技术都能解决同一个问题。
所以解决问题本身才是重要的，而不是纠结用什么技术。
学习技术很容易，只要你愿意花精力去钻研，总会弄明白。
那么，重要的事情是学习能力，执行能力等等。
或许，这也是为什么微软找人看中的是一个人的潜力，而不是这个人目前会做什么。视野
视野决定了很多东西。
做事之前要多想，想想问题和其他问题的联系。做事前要多问问自己如何能做的更好。
要看的更多，更远，而不仅仅局限于解决当前问题。只有这样，才能掌握更多的东西，理解更多。其他
时间紧迫导致理想和现实的差距。刚开始大家想的都很好，理想很丰满，但是实际做的事情和构建一个可维护可运行的软件相去甚远，现实很骨感。
事物的波浪式前进。每当我们感觉要最终成型的时候，又从各个角落冒出来一大堆问题。