分享 我对待技术学习的态度
博文原文地址：我对待技术学习的态度
本文仅谈业余时间的技术学习，不谈工作中的要求。
技术固然要时时学习，因为更新快嘛，但对待技术上学什么，怎么花时间学，需要一个指导思想，否则浪费时间而且效果不好。
1）抓住主干，而非细节 最近很火的一句话是“你不要用战术上的勤奋掩盖战略上的懒惰”。放到技术学习上就先主理解主干后关注枝叶，比如 C++ 的好书很多，《Effective C++》和《Inside C++ Object Model》是好书，但它们都不是用来入门的，为什么？因为它们不是主干，语言实现细节和各种坑你都了解了，碰到实际问题依然用不好 C++。
2）尽量不折腾 不去折腾那些不成熟的技术，尽量用较为成熟的技术。在一年多之前，我用 AngularJS，MongoDB 的时候把我可给坑惨了，所以我下决心如果不因为工作坚决不碰 Go 语言，Node.js，要学不如学 Erlang。新技术应用场景不清晰，前景不清晰，生态环境弱，类库少，坑多不容易跳出来。简而言之就是风险大于收益。同理我也不喜欢用 Linux 而喜欢 Mac，Vim 的包也是别人弄好了直接 install 的。
3）尽量学习经典原理而不是浪费时间在细节上。 这一点条和第一点类似，多花时间学习抽象模式，设计原则，类型系统，看诸如《SICP》《The little schemer》《Essential of Programming Language》这种书，如果不是因为工作绝不浪费时间到《Dive into python》这种具体到语言细节的书上。
4）尽量学习形而下的系统而不过多上升到形而上的思想上。 上一点谈到了抽象模式和类型系统，但切不可单纯从思想上判断哪种语言一定好，哪种抽象模式就一定好，一定要结合形而下的系统综合看待，学习 C 语言就要随着 OS 学习，学习 Lisp 就随着编译器或分析器一起学习，学习 Ruby 或 Python 就跟着 web 开发来学习，通过某一类系统架构理解语言的优劣，通过语言来理解为何这么架构系统。
5）学好那些通用技能。 比如：1，如何进行 Debug，2，如何阅读源代码，3，如何进行基本性能监控，4，熟练用好自己的编辑器和*nix 命令行，5，git 技巧，6，项目管理能力，7，关系型数据库的知识。
我觉着吧，你可以不喜欢特定的技术，比如 Angular, MongoDB, Node.js 等等，或者判定他们不适合你或你公司的应用场景，但不必要以“技术不成熟”为理由拒绝学习。
什么技术都是从不成熟到成熟的。只用完全成熟的技术，公司产品难有竞争力，个人难找工作，社会也没进步，扯远了，哈哈。
关于你说的不学细节我也不赞同。貌似这是计算机科学家的态度，不是程序员的态度。基础当然重要，但要形成生产力，还是需要细节，大量的细节。
@whitecrow 我不知道 Angular 和 Java 的那个框架有什么关系，也许原理类似，这很正常，Angular 从来也没说他那个是独创的，Knockout.js 比它还早出现呢，但 Java 能广泛应用在浏览器？
我不反对你反对 Angular 或 Node 或其他，我反对的是你的理由是他们的技术不够成熟。Angular 和 Node 还要多成熟你才能学？当然你学了一些之后发现不适合就不学了，这个完全合理。
其实原则就是学那些最基础的，同时吃透那些焦掉了的技术。后端比如 Ruby，前端比如 JS 吃透，这些搞定，看看那些基础书，系统啊，编译器啊，算法啊，其他那些什么新玩具不过是新壶旧酒，底子够了一摸就能用了。
没有实际效果的玩意千万别浪费时间，比如编辑器，Textmate 看熟了菜单快捷键，基本上 3 天时间的研究可以秒杀一堆 Vim 熟手啦。
谈一下作为一个工程师，我对于技术学习的看法
首先，技术是用来解决实际问题的，一个新技术的出现并且能有人用，首先证明了这个新技术确实在某些方面能够更好的解决一些类型的问题，所以，决定你去不去学习新技术的动机在于你是否已经觉得这些问题让你感到足够的苦恼了，已经严重的影响到了你的生产力，或者说原来的方式已经达到了性能的瓶颈，你不得不去寻求新的技术。
第二，人的精力是有限的，一个人即使再有天赋也不可能解决所有的问题，所以有选择的进行学习是很有必要的，学什么，怎么学非常重要，愚蠢的工程师学案例，聪明的工程师学方法，卓越的工程师学组织，有个故事我很赞同，如果你只看到一块砖，那你最多只能成为一个好的工人，如果你看到的是一个大厦，那你可以成为一个好的建筑师，但是如果你看到的是一个城市，那么你就能成为一个伟大的工匠。
第三，对于一个好的工程师，折腾是一种常态，他需要为了找到更好的方案而进行无尽的折腾，折腾是可以创造奇迹的。当然前提是有明确的方向，很多人折腾不出东西来浪费了大量的时间是因为出发点是错的，而不是折腾这件事本身是错的。还有在做一件事情之前可以多咨询下比你做得好的人的意见，可以直接跨越掉很多坑。
第四,现在编程语言非常多,基本上从几种大的编程语言扎下去研究最后达到高度都是差不多的,一通百通,关键还是看个人喜好,语言说到底也是一个工具,用得好不好关键还是在于人,所以没有必要去纠结在语言的选择上,和建房子一样,如果你喜欢建小木屋,你可能用斧头就可以了,如果你只喜欢建大厦,那你就得用吊车,但是不可能所有的人都需要住大厦,小木屋同样美丽.学习一种语言的关键在于学习这种语言用来解决问题的思维方式.不同的语言解决问题的思维方式是有区别的,同一类思维方式的就完全没有必要重复学习了.不过大部分工程师对于拥有更好的工具都存在不同程度的癖好,至少我个人是这样的,lisp是终极神器,你值得拥有,但是并不意味着新手应该从这里开始.但是lisp给了我们一条很重要的指导意见,不要过早的去优化你的程序,程序应该从底向上去构建,和建房子一样,基础越牢固,房子越稳.对新手从哪里开始我给些个人的建议,如果你向往gui开发,从c++开始是一个不错的选择,mfc,wxwiget,qt,这些都是经典的gui框架,任何一个都不会让你失望,如果你向往web开发,从ruby或者python开始,rails和Django都可以让生活变得很美好,如果你更多的是想来点软硬结合或者只想和机器打交道,你还是从c开始吧,c语言可以告诉你机器是怎么思考的,java的优势在于跨平台,别的语言跨平台都是坑,c#在开发windows软件上用户体验非常好,总之,根据你的兴趣点去选择从哪里出发,兴趣很重要,如果没有兴趣是不可能有所建树的.
第五，关于编辑器和 ide 的选择，不要为这件事情太纠结，工具只是为了帮助人更好的完成任务，而不要让工具成为你的负担，所以原则是选择你用起来最顺手的，值得长期投资的去学，说哪个编辑器好或者不好都会挑起一场战争，我就不说了，出生在 80 年代以前的程序员基本都是 emacs 粉或 vi 粉，外加少量 nano 粉，90 后 sublime 居多，因为个人觉得 lighttable 做得也不错，所以在这也提下，虽然我很少用带 gui 的编辑器。我不用 gui 仅仅是因为我出生在 80 年代，那时候机器都很差，用不了 gui，后来机器好了习惯已经形成了，没必要改了，并不是因为 gui 不好，我觉得 gui 还是可以提升生产力的。所以如果不是真的觉得顺手新手没必要浪费太多时间在这件事情上，你写代码好不好不会因为你用了 vi 或 emacs 你就变身咸蛋超人了。
反 geek 思想，要是每个人都这么做，技术也就变的枯燥单调，没有了发展，如果没有了巨人，又怎样站在巨人的肩膀上。但如果只是为了个人生活，工作，那么这就比较实用。
观点有对有错。
第一点，在初学阶段是这样，先抓主干，理清脉络，然后再去看细枝末节。然后慢慢的形成体系。而且不光是编程语言，还有很多其他计算机知识也是类似的。并且一定要对计算机有系统的学习。但是你不能把自己就定位于初学者。如果永远是初学者，那么请转行。
例如以前我面试的时候经常问一个很基础的很简单的问题，但是很多人都不能很满意的给出答案，问题是：main 函数里面不停的调用 main 会是什么效果。
代码如下
int main(void)
{
main();
return 0;
}
其实这个问题深究下去是一个计算机很本质的东西，函数调用依赖栈，局部变量在栈里面分配。这也是很多安全问题的本质原因。你可能觉得这类问题是细节问题。但是绝对是核心问题之一。如果这类问题答不上来。只能说明知识不够系统。
所以说初学的时候抓住主干快速入门。入门后继续深入学习。
第二点，如果一个程序员对新鲜事物都没有学习的欲望了。还干程序员干嘛？不管成熟不成熟，花点时间了解下，然后根据需求选型就可以了。就像第一点说的。如果真的不要不自己定位于初学者，知识比较系统，学个语言，学个库，真的需要花很多时间么？如果发现不好用，或者你不喜欢，或者不适合你的场景，或者是坑太多，你不选型就可以了啊。和学不学有什么关系？
刚好你提到了 golang，里面有一个特性，分段式栈管理，刚好第一点提到了栈，如果不能真的理解函数是怎么调用的，看到这句话也仅仅是一个宣传语。
第三点和第四点 我觉得理论和实践要结合，要深入学习任何一方面的东西。理论和实践都非常重要，没有谁轻谁重。学理论能够知道大体上这东西是什么，怎么来的，怎么想的。但是实际中你去做的时候，会遇到很多工程问题。这类工程问题。对于程序员是很有价值的。并且如果你要把理论理解很清楚很深入。需要自己去实际做点东西的。所以我觉得两类书籍都是有价值的。第四点和此类似
总结就是不要光看理论，泛泛而它，不要光只知道怎么用，但是不明白为什么，两个都很重要。慢慢的积累就会形成一套自己模式，这些模式，时间长了，懒得给别人解释细节了。就是你说的形而上。很多时候行家只是一句话的问题。但是外行看就是形而上。因为搞太久了。懒得说很多句话去解释了。
第五点，不评价
支持，道理上是如此，但我认为这些内容都是对有经验的人来说的，但有经验的人往往有自己的方法了，总结的意义不大了...
对于新手或者刚入行的人来说，个人对各种经验总结都持悲观态度，试着逐一举反例
抓住主干，而非细节。 那么，什么是主干？什么是细节？你可以知道，但新手怎么能够知道，我们也可以告诉新手什么是主干什么是细节，但要做不同的事情主干和细节是不同的，前辈们真的有那么多精力么？比方说学写 Rails 可能很长一段时间都不需要自己亲自动手完成一个类，或者也几乎不需要操作各种 IO，但我想写一个统计代码行数的小脚本则反之了。
尽量不折腾 和 1 类似，什么叫折腾？对于新手，本身就是白纸一张，做任何事情都是“折腾”。而且相对来讲，做网站 NodeJs+MongoDB 组合对一个完全新手来说可能是最不折腾的了，因为只需要学习 JS 一门语言足矣。而且在基本 CRUD 上，是不可能遇到坑的，碰到“坑”完全是因为用错了。
尽量学习经典原理而不是浪费时间在细节上 原理、思想很重要，但是，一个实践不足的人能够理解他们么？此外，编程是极重实践的工作，任何思想最终都要化为一行行实实在在的编程语言的代码，思想和模式是提供思路的，语言的语法、特性、类库是解答问题的，两者分工不同
尽量学习形而下的系统而不过多上升到形而上的思想上 学习 C 语言就要随着 OS 学习，学习 OS 本身就是一个巨大的范畴了，数据结构、算法、汇编等等，而 C 只是因为历史原因采用其实现而已。 学习 Lisp 就随着编译器或分析器一起学习，抱歉不好举例，但个人认为编译器和分析器与 LISP 或者 HASKELL 之类函数式语言也无直接关系 学习 Ruby 或 Python 就跟着 web 开发来学习，至少 Python 在科学计算领域也有着很大的市场，Ruby 也在测试领域还有 PAAS 领域有着很重要的地位 上边每一个选择都是巨大的坑，彼此之间完全不相干 此外，通过某一类系统架构理解语言的优劣，优劣是通过对比得来的，也就是说，你要用 LISP 和 C 写操作系统，用 LISP、C 或者 Py、Rb 对比写编译器，用多种语言写 Web 对比后，才能说出优劣，这完全是实践出来的总结
我认为成长只有实践，走弯路很正常、感觉困惑也很正常，遇到了，停下来，反思、交流，我觉得这是个穷则思变的事情，各种经典书籍里记载的也不是真理，思考的原料、实践的方向而已，在瓶颈之前，不要想太多
为什么我说在工作之外，不要关注细节（特别是语法细节）。因为细节这个东西，实践的时候，查查 Guides 和文档就够了，再不行就 Google 一把，故意去学习这些细节并不能提高你对编程的理解，或者说提高得太慢。
如果你只看到一块砖,那你最多只能成为一个好的工人,如果你看到的是一个大厦,那你可以成为一个好的建筑师,但是如果你看到的是一个城市,那么你就能成为一个伟大的工匠.
如果你只看到一块砖,那你最多只能成为一个好的工人,如果你看到的是一个大厦,那你可以成为一个好的绘图员,但是如果你看到的是一个城市,那么你就能成为一个好的规划绘图员.
#7 楼 @whitecrow 以MongoDB现在看来作数据分析是个不错的容器，当时我学它用它做业务方面的数据库，被坑了 为理由来暗示MongoDB是不成熟的技术
就相当与 自行车现在看来是个不错的陆上交通工具，当时我学它来试图横渡大西洋，被坑了==>自行车真是个不成熟的技术
因为新技术应用场景不清晰？对啊，自行车说明书上好像真没有写不能在海上骑呢，问题是我们是工程师啊，不是什么小白啊，如果连某项技术大致的应用场景都不能了解，还要啥自行车呢……
学习 Lisp 就随着编译器或分析器一起学习
LZ 你是不是对 Lisp 有什么误会==
这一点条和第一点类似，多花时间学习抽象模式，类型系统，看诸如《SICP》《The little schemer》《Essential of Programming Language》这种书，如果不是因为工作绝不浪费时间到《Dive into python》这种具体到语言细节的书上。
btw，我猜 LZ 这基本前面提到的书里没一本看完过 (
#32 楼 @whitecrow 没有…只是觉得扯类型系统的话 TAPL 更加好吧……哈哈哈 (写 Rails 的管得着类型系统吗 233
你的观点去掉例子的话没有什么大错，但是都是大条道理。什么是大条道理？就是把内容换到其他领域来说也一样一个意思。讲大条道理很多时候的一个坏处就是空口说大话，个人觉得与其说大条道理不如分享自身熟悉领域的经验 (LZ 说类型系统什么的恐怕连 M&M 类型系统都没搞清楚吧)，比如 Mongodb 怎么坑、Erlang 怎么完虐 node 几条街、Lisp 连 Parsing 都不用怎么来学编译原理之类的
如有得罪，多多包涵，就是这样。
#34 楼 @bugmenot 我既分享过大条道理，也分享过自身熟悉领域的经验（http://ruby-china.org/topics/17423 http://ruby-china.org/topics/19349）。后者固然在技术论坛比较政治正确，但抽象的或总结性的思考，我相信也是有人需要的。
看楼主的帖子，受益匪浅，学习一个新的技术，或在框架，我都停留在表面，没有深入学习，只是为了赶工期，只要代码能正常运行就好了，没有从根本上理解这个技术或在框架的精髓。以后要多多向楼主学习
对于第一条我很认同 抓住主干 而非细节 我学 ruby 的时候 看了基本语法 就开始看元编程了 其他的细节用到再说 但是对于折腾这点来说 我有不同见解 我觉得多折腾未必不是好事 新手往往起步的时候比较脆弱 遇到错误可以能就没法下手 打击积极性确实是这样 但是总是无痛起飞 那成长起来的小鸟能经历风雨吗？另外 AngularJS 的质量也还是能称得上稳固的 linux 的下像 Ubuntu 和 fedora 这样的发行版桌面系统的易用性也不差
不太苟同啊，简单说，没有细节，何来主干，让你做个 Login Form，你来和我谈模式，这种情况我带队的时候还真是经常碰到这样的，来一个项目要 POC，一天功夫可以快速弄个原型的，和我扯东扯西，各种模块各种分层都覆盖了，具体要做东西却是傻眼了。
另外，让我来说的话。如何 debug 和利用 google，stackexchange 是对新手最重要的，应该排到第一位。剩下提到的几点，其实正常人都应该没多久就能无师自通，除非这人写代码只是为了混饭吃。
细节是怎么做，原理是为什么这么做，由细节推动理解原理，根据原理可以去推导具体的实现细节。在选择技术方面上，了解该技术提倡的理念，发现里面蕴含的原理，比深究具体细节来的更快更好。一个技术如果在方向上出问题，具体细节的实现再怎么完美，都是徒劳的。就像托勒密地心说体系几乎完美的解决了各个行星运行轨道的问题，但是它从根本上就错了，无论它在细节再怎么完美和优雅。追本溯源，如果这个体系开始就确立了太阳为中心，根本不会不会出现那么多需要解决的细节问题。一个好的体系应该是解决问题，而不是制造问题。
#51 楼 @jeremy16601 我劝你好好说话！！！我谈谈自己的学习态度，你有不同的态度就亮出来，有不同的意见提意见。评论技术无非各抒己见，难道因为怕被说装逼就不分享不评论不表达，呵呵呵。
一大早看见这种评论真是恶心，很多人离开技术论坛论坛就是受不了这种语气，导致论坛越来越水。
#54 楼 @jeremy16601 楼主分享一下自己的看法而已，又没找你要电话号码，也没逼着你去信。你上来就说人家装逼，敢问楼主写的哪一点冒犯你了，让你用这么泛酸的口气说话？
