1、想要最大化创造价值，最重要的是两点。第一，会发现问题，并且判断出什么问题值得解决。第二，具备高质量解决某个领域问题的技术水准。
2、为什么程序员不自己单干？可以啊，那些说难的，就是能力不够罢了（不一定是技术能力）。
3、先问是不是，再问为什么。大部分 “我身边...” 开头的回答都是以偏概全的，只有数据才会给你真相。
4、英语是否会成为开发工程师的发展瓶颈？回答：不仅英语差会成为瓶颈，英语好还能成为优势，因为学习效率会比别人高。像我这样半路出家自学的人，只能靠英语了...
5、很多非科班出身的程序员经常会潜意识里给自己划定范围，啊这个是科班出身的人才懂的东西，我没希望了。你之前学了啥跟你以后能学啥没有什么本质联系吧。我本科学的是艺术史，只意味着我本科的时间大部分花在了艺术史上而已，不代表我以后不能再花时间在 CS 的东西上。其实很多所谓科班出身的人对于编译原理的理解跟你的差别也就是三个多月一门课而已... 如果真的觉得编译原理是自己的瓶颈了，那就下决心去学呗，可能并没你想象的那么可怕。
6、前端开发中有什么经典的轮子值得自己去实现一遍？答：Virtual-DOM。
7、有什么适合碎片时间看的计算机基础书籍推荐？答：学 JavaScript 碎片时间看犀牛书正好。我当年就是在公交车上看完的。
8、一直呆在舒适区往往就得不到提升，程序员能力的提升往往都发生在尝试解决一个从没解决过的问题之后进行反思的过程中。
9、前端这个词现在涵盖的内容也越来越广了，尤其是应用化了以后，俨然前端自己有一个迷你技术栈。我来简单勾勒下：
纯表现层。用户体验、布局、特效、研究 CSS 各种奇技淫巧，对于很多设计 / 前端兼修的人来说，技术层面就到此为止了。他们很多可能一辈子都不会写翻转二叉树，但他们也能搞出一些科班出生的人一辈子也搞不出的用户体验。当然不排除一些走 creative coding / 数据可视化路线的人需要对物理、数学、甚至计算机图形方面的知识进行针对性地强化。
应用实现层。可能是大公司初级工程师主要干的活：拿着别人设计好的框架、工具去实现具体的应用逻辑。实话实说这个层面对计算机基础的要求确实不高，只要对 JavaScript、CSS 这些领域专门的东西基础扎实 + 学习能力 OK 就可以了。但是这个层面其实需求巨大，而且有一个独特的需求：开发效率。要提升效率就得对手上的工具了解得非常细致，比如 XX 框架的 N 种优化小窍门之类的。而这种东西只能靠实战经验去积累，基础再扎实影响也有限。
应用架构层。技术选型、开发底层框架、制定开发规范、设计应用结构... 这些东西就涉及到知识的广度和深度了，对业务需求的理解很重要，而且碰到具体的纯技术问题的可能性也大得多。编译原理、算法、数据结构在这里都会派上实际的用处。
基础设施层。自动化构建、部署、测试、加载方案、性能优化、代码质量管理等等... 这一层更加技术化了，而且涉及很多所有软件工程共通的东西，并不局限于前端。
理念层。通过借鉴整个计算机体系中其他领域的思想，从根本上改进前端的开发范式。Facebook 的人现在做的就是这种事情。事实上能做到这一层的人基本不以前端自居了。
上面的这些层次并不是一个发展路线，不是说是个前端就一定要冲着最高的层次去，这不现实，因为每个层次都可以深入钻研，对于公司来说，尤其是大公司，往往更需要在一个层次深入专精的人而不是每个层次都半桶水的人（对于多层次专精的人的需求也是有的，但是这种一般都是 senior 职位了，不会太多）。
10、不看具体业务需求就谈一个前端是不是靠谱都是耍流氓。一个人称不称职，看的是他的技能树和他当前的职责是否匹配。有没有必要学习特定的知识，这是一个要看情况讨论的问题。假如一个人科班出身，基础扎实来做前端，那他可能很快就可以开始涉及架构层和基础设施层的工作，这是比较理想的情况。但如果之前并没有基础，那就看你有没有野心向其他层去发展了，如果你真的有兴趣，在研究过程中自然会发现自己的短板，并且有足够的动力去弥补它。
11、一个框架能不能火，最关键的不是技术实现上多 nb，而是在于这个框架是否代表了一种（在其所处的时代）先进的开发理念。
以上内容，来自尤雨溪的知乎