关于造轮子
学习使用轮子，特别是复杂的轮子， 最好是根据原理自行实践一个简单的轮子， 待造的轮子多了， 看到原理就有信心实现了，再学习新的轮子就更容易了。
因此不必纠结造轮子会重复，造轮子本是学习的一种有效的手段。
关于广度与深度
关于学习一门新语言
云风的程序员应该怎样提高自己一文中，有这么一段话我是很认同的。
精通一门语言是最基本的要求。所谓精通，就是要了解这门语言的各种阴暗角落。用每一样语言特性的背后的代价。知道在面临各种问题时用这门语言解决该问题的惯用法。大部分通用语言都会有设计缺陷，表现在具体方面就是面对某些问题，写起来直接了当，而另一类问题时却要绕很多弯弯，这些绕弯弯的部分就需要用某种模式去弥补。我认为，所谓编程的设计模式，并不是跨语言而独立存在的，它们是强烈依附于编程语言的。《设计模式》这本书，我读过的版本是基于 C++ 的，设计模式被谈论的更多的是在 Java 社区。这类模式都有很深的语言烙印。我们学习设计模式其实学的就是一门语言的惯用法。
初次学习设计模式时，肯定会有豁然开朗的感觉。但不应把自己陷入其中。为了提高一次层次，就必须精通至少第二门的语言。我的第一语言是 C ，第二语言是 Lua 。但对于许多人，肯定会有很多更好的选择。多看看不同的语言下解决问题的不同方式，有助于提高编程技能。
精通两门语言 —— 编译语言与脚本语言 —— 有此能力， 再学习其他语言，现学现用, 代码的水平也不会太差。 因此，确实需要将主要精力放在主要的两门语言上。
理论上图灵完备的语言都可以做其他语言可做的任何事情，区别于方便与否。
学习英语，练习写作的思想与此有共同之处。反复背育经典的文章，达到每一个细节了然于胸，后面更多知识的学习就会有了感觉，触类旁通, 水道渠成。
自己
有人喜欢抱怨说如今的自己为生活所迫做出了各种让步与妥协，并不是真正的自己。 可你要知道，也有很多人即使面对社会压力也从未选择妥协， 所以“真正的自己” 这种说法只是借口而已。 选择了妥协自己， 选择了对世界妥协的那个你，就是真正的那个你。 — 网友
一悟惊醒梦中人, 如何才能有如此的表达能力？
只有两个标准甄别评论者的价值，一个是他预测未来的准确率， 另一个是他亲自下场做的成绩。 按照塔勒布的说法，只有攸关者的意见才是有价值的，因为只有下场了（成为用户也一种下场的形式），承担了真实成本，其洞见才值得一听，无关者的意见都是廉价的，不要往心里去。
踩坑
见过很多人都有一种不撞南墙不回头的精神内核，包括我自己。
如果能将前人的经验转化成自己的认知，那么踩坑的机率就会大大减少了， 然而我在这方面的能力就很弱，不亲自去踩一道坑, 就是转化不了自己的认知。
所以， 如何能判断哪些坑是可以踩，哪些坑是不必踩的呢？
将前人的经验转化为自己的认知这种能力是可以锻炼的，作为一个新手，踩坑是基本素养，有些人可以靠背诵达到表象的转化，因此能提高不少成绩，但欠下的债也终究会尝还。这里又有一个特例，那就是抽象能力, 抽象能力强的人，也确实会在理论层次学习上更容易将知识转化。从这里看，我是一个偏工科思维的人。
新手的踩坑, 是为了打基础, 便如学习绘画过程中的临摹，必须积累足够的素材，打好绘话基本功，才能在此基础上创新。创新的过程，也是知识融会转化的过程。
抽象
计算机世界本就是对现实世界的抽象。人们造不出来没有见过的东西。
在学习技术的时候，总是想知道，为什么要这样做，技术是如何发展的，选择的动机是什么。而经过足年累月的发展，现在的社会就对新手很不友好, 一开始就是地狱难度, 除非有大神带路，否则对新手的体验非常不好。
我想对我建立自己的知识体系的这条路给写出来，学习计算机知识的过程与现实中成长的过程也是互通的，只有对这个世界了解得越多，才能过得更加自由。
这些真得可以写一个专栏，甚至可以出一本书，这真得很有普及意义，虚拟与现实
字符串与编程
从字符串的角度禅述, vim 是高效处理文本是勿庸置疑，文本本质上是字符串。
而字符串对于编程的人来说，重要性绝对占据90%的场景。
键盘输出的是字符串
字符串是人与机器沟通的媒介
系统的配置是字符串
文件的处理是字符串
语义分析的是字符串
代码的编写，文档的编写是字符串
使用字符串来画UML相关图，画公式，效率是要高于相关的图形工具的。
而vim 是操作字符串最高效的编辑器，从这个角度来看, 学习VIM的好处，也绝对是大大的。
开发与优化
开发的过程中，不强求考虑到优化，而是根据每个人的自身能力，顺其自然地想到哪一层就可以开发了，还没有开发，就过渡地考虑优化，往往是事情迟迟开始不了，啥都不敢写了。
能力是一步步提升的，先解决有无的问题，再考虑优化。
如何分析开源代码
先学会开源框架的使用，
然后搜索是否有相关的设计文档或者已发布的分析blog，初步了解设计框架。
在初步了解一些分析后，应该就会有疑问, 搞懂不知道的术语, 某些设计的原因。
一个软件系统就是一个小宇宙。别期待有什么高明的文档，把自己当成物理学家，物理学家没有上来就了解整个宇宙的。
找好切入点:
从使用的api作为入手点开始跟源码
从某些专业术语的命名中，结合现实生活的案例构建参考模型。
画出代码的UML图, 以便于理解各类之间的关系。
随着深入的了解，逐步搞明白不懂的设计的出发点，术语，要解决的问题。
配合一些辅助方法，加log, debug
猜想, 主干与分支，分支与猜想没有出现反例，就先不管分支，如果出现明显反例，就搞懂分支。
task stack 保留
产品化思维
开发离开不产品设计思维，Android 的theme 就是统一设计风格，如何按照一个拙劣的设计来实现产品， 开发是没有动力的，而且技术上也是处处受限的。