总结一下：用力地啃好书。专心地做好项目。剩下的，时间会帮你搞定。

开始读书了

你就明白：你以往东拼西凑几十篇烂文才明白的事，书上那几页纸都写着，而且详细的很。

多找第三方开源

你就明白：原来工作摸鱼不是梦。

太随便用第三方

你就明白：某天需求一变，它兼顾不到，可以把你往死里坑，坑到你得去看源码。

学了OO, 熟悉了“设计模式”, 领悟了IoC和DI, 让我大概感觉到了程序应该有一些结构, 而不是简单的把逻辑用if-else写进去, 这是我感觉自己能力提高的第一次飞跃;

看SICP和CTM让我开始理解程序和编程到底是什么, 特别是对CTM里的最小表达力原则的理解, 这是我编程思想的第二次飞跃;

学了函数式编程思想为我打开了另外一个世界, 引导我去了解haskell, 去稍稍的学习了些category theory(这个是真的难…), 这解放了我编程思想的另外一个纬度, 抽象能力有了质的提高(主要体现在generic programming的能力提高, 高级类型的灵活运用), 我开始有意识的去降低核心程序的"熵"(程序的可能性越多, 各种可能性的概率越均等, 熵越高), 使得程序更容易理解(熵越低信息含量越低则越容易理解), 而把系统的灵活性(比如状态, config等)隔离在核心逻辑之外(这样使得变化可以在一个地方, 比如系统setup时, 集中理解, 然后用理解的setup来很简单的推理核心逻辑在这种setup下会怎样运转), 这样就使得程序的核心复杂度更加接近于核心业务的复杂度(业务的熵是本质复杂度无法用调整程序结构的方法降低, 但是, 本质复杂度也是可以降低的, 请往下看), 但是又没有写死整个系统的灵活度; 这是第三次飞跃;

然而, 最大的飞跃是当我最终把重点从编程本身转移开来之后, 当我开始去看分布式系统算法, 去理解各种云服务的特性, 去深入了解我所工作的领域或者说业务, 去了解和我们组有关系的其他部门的业务, 去了解ML(由于业务相关); 去了解需求获取, 怎样拒绝不合理需求, 怎样调整和简化需求(降低业务本质复杂度的关键), 甚至创造合理需求，去了解测试, 监控, 部署, 构架, 运维, 项目规划和人员部署, 思考为什么junior SDE会犯错, 帮助mentor别人, 甚至开始关心组内的技术文化建设;

这是因为“编程是最重要也是最不重要的事”

这是因为编程作为把思维变为实现的这个循环的最后一步(然后写好的程序会成为新的思考输入和基础，开始新的一轮迭代开发)，它和一个项目一个系统的所有其他方面都息息相关：需求获取，问题抽象，测试，监控，部署，框架运用，系统间集成，灵活性，未来拓展性，易用性，系统健壮性，多版本实验性，高层业务决策等等，这使得编程变得无比重要(所有的一切都需要编程来最终落到实地)，也毫不重要(编程被所有其他一切所约束和指导)。能够支撑这些所有上层思考的程序才是“好程序”，能够支撑所有这些思考的程序员，才是好程序员。学好/学会编程这件事是把所有需要思考的东西都弄明白都学好之后的自然结果。而把这些思考留给别人，自己只做思维和程序的翻译器(区分创造者和工具人的关键)，根本无法写出好的程序来。这也是DDD(Domain Driven Design) 的精神之一 （关于DDD的精神，参见此文的最后一段， 阿莱克西斯：在做程序员的道路上，你掌握了什么概念或技术使你感觉自我提升突飞猛进？ ）

以上引用出自自学编程需要注意什么？

我觉得: 我们在积累技术能力的同时一定要开阔眼界, 这样才不会陷入一个"局部最优解" (随便逮着一个点都能开阔人类边界的天才除外); 眼界太窄以至于学了一点点东西就觉得自己"天下无敌"了, 是我们进步的大敌 (也是曾经是我最大的敌人);