主要目标规划必须具备一定的挑战性，需要规划出不可能完成的目标。过度规划本质上是一种贪婪算法，目的是目标价值最大化。因为一切皆有变数，如果其他目标能够提前完成，就不妨利用这些时间去完成更多的学习目标。总之，前途必须光明，道路必须坎坷。
学习计划最好能结合工作计划，理论联系实际结合，快速学以致用。比如，本季度规划去做一些数据分析工作，那么不妨把学习目标设置为学习统计知识。
所谓麻雀虽小，五脏俱全。如果让你来做造物主，设计麻雀和设计大象的复杂度并没有明显区别。一个看起来很小的业务需求，为了达到极致，所需要的技术和能力是非常综合和高深的。真正的高手不是拿着所掌握的技术去卡客户需求，而是倾听客户的需求，给出精益求精的方案。完成客户的需求是一场擂台赛，真正的高手，是会见招拆招的。
基础技术和业务应用技术必然会有不同的关注点，没有高低之分。之所以产生这种误解，有两个原因：
基础技术相对成熟，有比较完整的体系，这给人一个高大上的感觉。业务应用技术相对来说，由于每个团队使用的不一样，所以成熟度参差不齐，影响力没有那么大。
基础技术的门槛相对来说高一点，考虑到影响面，对可靠性、可用性等有比较高的最低要求。但是门槛高不代表技术含量高，另外成熟技术相对来说在创新方面会受到很大的约束。但是最先进的技术都来自活跃的创新。
对比下来，业务技术和基础技术各有千秋。但真正的高手关注的是解决问题，所有的技术都是技能而已。
可行性调研的那些坑
工作中开展可行性调研时有发生。做可行性调研要避免如下情况：
把可行性调研做成不可行性调研。这真的非常糟糕。不可行性的结论往往是：因为这样或者那样的原因，所以不可行。
考虑到招聘成本，就算是在录用层面，有时候也无法做到。作为一个小团队的管理者，能够快速准确的获取团队成员的各种反馈信息，完全不需要“用人不疑，疑人不用”。用人的真正理论基础来自于“探索和利用”(Exploration and Exploitation )。不能因为下属能做什么就只让他做什么，更不能因为下属一次失败就不给机会。
让盘根错节的众多子系统运行起来是个不小的挑战。得益于SOA架构的普及以及大量编译、部署工具的发展，编译部署的门槛已经大大降低。基于应用层进行开发的公司，已经很少有“编译工程师”的角色了。但是对于初级工程师而言，编译部署仍然不是一个轻松的事情。
衡量一个系统成功的一个重要指标是使用量。随着使用量的增加和业务复杂度的增加，大部分系统最终都会碰到性能问题。 性能优化能力是一个综合能力。因为：
