有人问我"怎样才能成为技术高手"

有一位网友,今年大二,询问我怎样才能成为技术高手. 我并不确定如何定义所谓的技术高手, 但是既然问到我, 便列举一下可能相关的事实.

首先请明确以下事实：
A. 挣钱能力和技术能力相关，但不成正比。
B. 他人的信任与信赖和技术能力无关。
C. 泡妞能力和技术能力可能负相关，请谨慎面对。

   没有人知道未来是什么样子. 也没有人能够保证自己永远都是技术大潮中的弄潮儿. 如果你只是担心知识的老化, 担心能否长期的保有一份工作. 那么只需要不失去别人的信任，越来越熟练的做好本职工作就可以了。任何工作中当时用到的知识永远都只是很少的部分，只要别人给你机会重新学习，你的人生经验就会是你最宝贵的财富。

   大二的小孩不要每天尽整些没用的东西。认真学好自己的专业课。做软件开发并不需要什么高深的知识，但是接受知识传承，得到全面教育的时机却是一去不回的。

   不要怕学得多，更不要自以为学得多。我在学校的时候，横扫图书馆的哥们并不少。

    读了书并不意味着懂得了道理。用自己的语言能否讲述学过的内容？能否用个简图勾勒Unix内核的结构？学过一门语言到底它有什么不同，能否勾勒发展的脉络？你学过的东西并不是你的东西. 你既无法消费它,也无法贩卖它. 在书本以外你是否真的意识到这些知识的存在性? 最重要的问题是, 你创造的东西在哪里？

    读书开始的时候半知半解是正常的。这就如同张无忌背七伤拳经，总有一天你会懂得，只是需要不时的去回味。数学典籍中经常有这样的说法，本书内容是封闭的，只需要某某领域知识，但是掌握它需要数学成熟性。成熟是需要时间的。

    读书不是以数量取胜。一个领域中类似的书只要细读一本，完整的读下来，读的时候多方参照，做简短的笔记。读一些原始的文献，读大师的原著。尽量选用英文的经典教材。懂一点学科的历史，知道什么是文化。了解一些学术界的八卦，吹牛的时候多一些谈资。
    
    学习任何一个领域都需要深入, 需要掌握大量的相关细节, 因为只有这样才能够不再被细节问题所干扰, 而集中精力于真正的思想核心. 

    拳不离手，曲不离口。连Knuth老兄都在勤奋的敲程序，所以请不要找借口。

   天下没有免费的午餐。不付出相应的成本，无法得到相应的回报。学习没有捷径，只有方法。只是方法正确并不能保证你走到终点，毅力，机缘都是不可或缺的。你是否能够1天10小时以上持续地考虑同一个问题，是否能够保持同样的注意力坚持到每本书的最后一页, 是否一年365天对新鲜事物总是保有一份天真的好奇。

   在工作中除了抽象的思想和具体的技术知识之外，还有大量小的trick. 例如调用equals的时候把常量放在前方if(MY_CONST.equals(myVar)). 一般不可能通过书本学习掌握所有这些技巧，只能在编程的实践中观察总结，更多的时候是要你主动思考，重新去发现这些方法。一个人的工作效率很大程度上是受其工作习惯所制约的，你是否在随时随地的改进自己的工作？

    怎样才能做技术高手？这个问题我并不知道答案。公司里所需要的也不是技术高手，而是能够解决问题的人。不过如何培养合格的程序员，在公司内部也有两种看法。adun说要给他们指明职业发展的方向，关心他们遇到的困惑。这是P大的浪漫主义情怀。X罗说要给他们可以完成但是不易完成的任务，等待大浪淘沙后的结果。这是T大的现实主义精神。

    开源是不可阻挡的历史洪流，我们只能改变自己的思维方式，调整自己的行为目标来适应它。

    面对未来的挑战，Alan Kay有一句名言：The best way to predict the future is to invent it。如果你不知道该怎么创造，那就先从捏造开始练习吧----事物之间总是可以建立关联的。

我觉得保持长期的兴趣是很重要的。

另外，读完了一本书不等于完全掌握了书中的知识。有些初哥架构师很喜欢以读书多来傲人，例如：我读过DDD、我读过PoEAA、DDD上如何如何说、PoEAA上如何如何说。以这种炫耀的心态来读书，很多时候不过是获得了辩论时占据上风的快感，其实对于提高自己的技能，未必是很有效的。

当然我不是说不应该多读书，只是说不要满足于读完了很多书。

孔子说：“多闻阙疑，慎言其余，则寡尤；多见阙殆，慎行其余，则寡悔。言寡尤，行寡悔，禄在其中矣。”
孔子的求禄妙方，后面一句听起来很俗气，距离某些人心目中神化了的孔子形象很远。不过前面一句说的是没错的，这是正确的学习态度。

解决问题的能力并不完全等同于个体的编程能力。《人月神话》中说软件开发的复杂性和成本大部分是在沟通方面。

举个例子：我们都是程序员出身，假设我们自己有能力解决任何编程问题。但是没有美工的支持，我们做出来的东西很难用，界面很难看，没有人愿意买。

将软件问题全部归结为编程问题，和将编程问题全部归结为算法问题一样，都是偏颇了。庄表伟以前曾经在JavaEye提出过强烈置疑：算法算老几？

把Martin Fowler拉来，详细问他《《计算机程序设计艺术》某一卷某一章中某一算法到底讲的是啥，他十有八九也讲不清楚。

关于如何解决问题，我到是推荐这位同学去读一下《麦肯锡方法》、《麦肯锡意识》两本书，这两本书并不是砺志书。

随便说几条
1. 时间, 付出和收获成正比
2. 学习方法 很重要,要勤于思考,多对比,多想为什么,多动手.
3. 足够广泛的兴趣 技术上没有门户之见, 其它的如经济,医学,宗教之类的都最好有感兴趣的领域

个人从业快超过10年了,感觉这领域没有真正的高手一说,术业有专攻,闻道有先后,人必须要像海绵一样不断吸取知识, 逆水行舟,不进则退,老话还是很有道理的

其实以现在的发展趋势,代码只会越写越少,而不会越写越多. 语言,框架和类库,各种模式的应用(典型的像builder) ,都会让代码行数减少.
因此,代码行数并不是我们要追求的

说来说去,就处理代码这个问题上,还是技术层次的问题,不同层次的人在同一个问题的可能就是两个完全不同的结果

在学校里学到的知识不实用，学明白也不容易。干活不需要明白太多道理，想干的明白就不一样了。



也算看了一些经典书了，感觉没有理论指导不成，光理论也不成，概括的知识多是百无一用，实用的知识又容易过时。概括的知识实践中慢慢领悟，实用的知识用到哪学到哪。


挺有意思，自以为学的多还是因为知道的少。



j2ee design and development 上面粗略的给了一些trick。研究好的开源项目源码是个不错的选择。
同意，实践、研究源码、多看些经典书籍，站在巨人的肩头，多总结，多思考。



呵呵，还是现实主义好些，浪漫主义不适合培养程序员。

有人认为我的这片帖子中显得很自以为是，只是在嘲弄初学者。可我事实上是在非常认真的回答问题，介绍我所知道的相关的事实。

难道现在的小孩都只能接受安抚的话语，而不能聆听一些真正的事实？

我觉得最重要的是兴趣吧，要是没有兴趣就得有毅力
其次是能力

看不出哪里有嘲弄初学者的意味，
对于这种想法，只能说仁者见仁了。

总结一下dlee的观点，1.同意老庄的观点－算法不算老几，2.martin fowler不怎么懂算法，而且这是光明正大的，3.麦肯锡的方法论是有效的。

哈哈 有趣