姚冬回答的非常好，我狗尾续貂的说几句。 我们都知道学习能力很重要，那么学习能力从何而来，除了去看书上课这种，如何在实践工作中学习成长？ 我之前微博说了一个笼统的概念，什么是能力？ 对待问题的态度，以及处理问题的思路和方法。 先说态度 你服务器偶尔出501错误，也许比例不高（知乎也出现过很多次），很多程序员，没错，是很多，假装看不见，不在乎，或者归咎于人品问题。 这就是态度问题。 再往后，负载高了或者其他什么原因，突然频繁出现501错误，不去追寻深入的原因，而是找各种借口， 什么IDC服务商不好，服务器品牌不好，操作系统不好，数据库不好，CDN不好，网络状况不好，web server不好，甚至，直接对Boss说我们被DDOS啦！（遇到过，帮他Boss找过多个安全专家会诊，最后发现根本不是DDOS，是程序员太烂。） 这就是态度，触目惊心，如果能对问题有敏感性，能知道对任何小的，轻微的问题有足够的敏锐度，你就有了一个快速成长的基础。对问题的敏锐度是非常重要的。很多性能或程序逻辑上非致命的bug，在不够敏锐的时候是发现不了的，但是一旦进入特殊场景就会骤然爆发，你多一点敏锐度，就会减少这种危机的风险。 第二个态度是解决问题的态度，有人对自己的解决方案信心满满，认为万无一失，但有的人就会多留一条后路；就好比你说我服务器要不要做安全加固，肯定要做对不对，要做到尽可能严谨和周全，但是你数据库保存密码的时候是不是还要加密?而且要随机salt，不就是防止万一依然有漏洞被人拿库怎么办么。程序也一样，以前写的一些服务端守护进程，有bug，会莫名其妙的终止，这个bug当然要定位，要修复，但是同时，写一个cron检查这个守护进程状态，一旦遇到终止给予自动恢复，这就是第二手准备，即便你多么不希望他执行，这个准备还是要做的。对问题 做两手甚至三手准备，也是优秀程序员，架构师的关键素质。 第三个态度是基于沟通与理解的态度，产品或运营提了一个不靠谱需求，一句话打回去当然很爽很威风，但是有没有仔细沟通分析过，这个需求基于怎样的实际诉求，这个实际诉求有没有更合理的实现途径，一句话“这个没法做，这个实现成本太高”，不是正确的沟通态度，而且，最优秀的产品，往往是实现了那些原本人们认为无法实现的诉求。 这样的态度，才有了一个持续进步的基础，下面说思路和方法。 优秀 的程序员和平庸的程序员，如果只看敲打代码的速度，我觉得是分不出来的，也许每人都可以一天写很多行代码，但是遇到问题后，平庸的程序员的解决效率，和优秀程序员相比就会有天壤之别。 所谓解决效率，不外乎对bug的分析、定位，以及 思考。 最基本的一条，看执行日志，看各种日志，web server的日志，数据库 的日志，慢查询日志，binlog日志，php的错误日志，等等等等，线上出问题瞎猜连日志都不看的大有人在。看日志不仔细不完整的也大有人在，你能去认真研究日志已经超越很多人了。 第二条，模块测试和断点分析，程序员一个坏习惯就是上来就写很大一坨代码然后再执行，不知道一个模块一个模块来写来测试，执行出了问题不知道设置断点，缩小范围逐步分析。断点分析非常简单，将整个代码中插几个中间输出，观察哪个环节出了问题，或者观察每个环节的系统开销，对调错和性能优化都非常重要，高手们大概认为这是ABC的东西，但是就这玩意我看到的大部分程序员都没有这个习惯。 第三条，错误信息 的理解和搜索，搜索引擎上有各种丰富的技术资料和技术问答，你所遇到的错误信息和错误提示，通常都能在网上搜索到，当然，搜索到后要结合你的场景认真思考，并理解透彻，而不是照猫画虎的去处理，否则可能这次运气好就蒙对了，下次运气不好又不知道怎么回事了。 第四条，不断总结归纳，对一个问题，一类问题，以及不同类型的问题，善于归纳整理，不断反思自己的问题，即便是不出bug的代码，你经过一段时间去回头看，也有很多思考不正确不合理的地方，有很多优化点，如果你觉得自己的代码一向牛逼，毫无破绽，那你一定是原地踏步，毫无进展。 关于 归纳总结，我说个案例 以前我们有个系统，请求量非常大，负载非常高，有个不错的技术经理来处理，他列了几个升级计划，都很靠谱，去执行了，效果非常好，然后我们跟进汇报的时候他来讲，做了几项升级，整体效果如何，然后我就批评了他。 我批评了什么呢？他是一起做的升级，然后一起观测的效果，那么这几个方案里，具体每个方案的实际效果怎样，对提升的帮助多大，他没有任何数据。所以对具体每个升级方案的价值和重要性，他没有任何概念。你正确的解决了问题，却没有认真的去归纳整理，你的收获是有限的。一起做升级不能说是错的，但是效果评估需要单独去做，而这个数据是非常有价值的，知识积累，不是你处理过的就一定有积累，而是整理过的。 大概就这些 最后重述一遍 什么是能力？ 遇到问题的态度 处理问题的思路和方法 这就是能力 点赞的那么多，答谢各位，补充几条思路吧，是上面几个方法的具体扩充 补充１：善于提问，你能得到怎样的答案，取决于你提出怎样的问题。 你遇到问题，你应该知道，从哪里去问，去问什么。 我常见的一个测试题是这样的。 数据库目前挂了，我就是服务器，我不知道为什么挂了，你是一个优秀的分析师，现在我来做响应，你问我问题，你问一个问题，我回答一个指标，然后看你能不能定位问题。（当然，我会根据所假设的问题回答所有数据指标），比如你问我数据库连接数多少，问我系统i/o压力多少，或者问我慢查询日志里有什么，等等，善于提问的人就可以快速得到答案，而不善于提问的人，就会猜测一堆可能，最终却一无所获。 有个真实好玩的案例，有个兄弟公司（前段时间新闻出来，卖了好像十个亿的样子），开始的时候服务端数据库不够强壮，负载起来的时候会出现一些问题，就请我去把脉，我一看windows服务器，SQL server (不要猜了，那是几年前，现在应该改了)，我说这个我不会啊，然后人家那么热忱当我是专家，只好硬着头皮上，我连基本操作都不会怎么办，我就坐在那里问问题，开始他们说是不是这样，是不是那样，我说你们不要盲目下结论，你们要是知道结论就别来问我了，我问什么指标，什么日志你们就给我查什么，我就一样样的问，他们现场操作去查数据，我问一个他们查一个给我看，查着查着，他们的工程师说，知道原因了！果然和他们开始的假设完全不同。 其实关键就是问问题的思路，他们一开始没有提出正确的问题。提出了正确的问题，他们很快自己就找到了原因。 补充２：善于划定范围，缩小问题区间。 前面提到的断点分析是一个非常常见的分析方法，但是很多场景，你甚至不知道是哪个程序出的问题，善于将问题范围化，也是一种归纳和分类的能力。 我曾在某个技术群出过一个经典测试，还记得以前微博上提到的一个经典面试题么。“从浏览器输入url到打开网页，中间经历了什么”，这是一个经典的综合认知的题目，基于这个题目，出一个更实战的场景测试是（这个场景其实９０％的网站站长和游戏运营商都遇到过），”目前有用户反映网站或游戏卡，请问如何分析原因，以及当前优先级步骤。“。结果在这个群里，只有我徒弟说出了完全正确的答案（０９年带过的）。优先级第一步是看在线用户数和当前访问数，对比历史，得到该问题目前的影响程度，来决定后续的优先级，以及减少分析范围。（这是意识问题） 分析思路，分成三大块，前端，网络层，服务端。当然这三块可以继续延伸下去非常多细节，但是至少，能先把问题分成三大块，然后基于一些显见的分析方式快速排除其中几个部分，再逐步细化问题，而大部分人只是从一个局部去思考，讲了很多局部细节却没有完整的纲领，所以这就是差距。 先想到这些，咳咳。
----------------------------------------------------------------------------------------------
问：池老师，我是个不爱互动的人，但是您所有的文章我都看了，非常感谢您的引导，我入手了人生第一台 MBP。现在问题来了，但是找不到更合适的人解答，只能求助于您了，如果您有时间的话。问题是这样的：我有个32bit unix file（开启一个服务进程），在 Mac 上执行时错误提示是：exec format error，但是在 Linux 服务器却可以执行，为何？Mac 上有可以运行的方案吗？期待您的回复，不胜感激。
答：Linux 和 OS X 是不同的操作系统，可以尝试在 OS X 里重新编译这个文件。
问：非常感谢！如果没有文件源码是不是就只能认命了？
答：可以在 Mac 上装 Docker，然后对服务进行端口映射就可以了。
答：茅塞顿开。谢池老师。
以上是我和一位读者的对话，这位小伙子在拿到答案之后像一缕烟尘一样消失无踪，之后再也没有出现过。
在微信上加了很多 MacTalk 的读者之后，经常会收到一些奇奇怪怪的问题，关于职场、关于选择、关于朋友、关于 Mac、关于技术等等，不一而足。但是我能回答的却很少。问题不好没法回答，问题太复杂没法回答，问题领域超出我的认知也没法回答，耗时太长的问题我也没时间回答，实在是惭愧的紧。好在偶尔也能够帮助一些小伙伴解决一些实际问题，心理上略感安慰，比如上面这个问题。
把这段程序员之间的对话翻译一下，大致是这么个故事：
一位读者有一个32位的 Unix 可执行文件，可以在某种版本的 Linux 服务器上正常运行，运行这个文件作用就是起个进程，开端口，然后与其他程序进行交互。但是这个文件拿到 Mac 上完全没办法运行。就在他趴在 Mac 上愁肠百结万念俱灰的时候，突然想到了「池老师」。不就是这个老家伙把 Mac 夸的像一朵玫瑰一样，让每个程序员都去采摘么？现在扎手了，你不管谁管？于是他给我发来消息，意思就是管也得管，不管也得管，您看着办。
我拿到问题一看，不难。Linux 和 OS X 虽然师出同门，都是从老前辈 Unix 那儿毕业的，但是后来毕竟各练各的，在 Linux 编译好的程序不可能在 OS X 上用，但是在 OS X 上重新编译一下可能就没事了。我把这个想法告诉了这位程序员，得到的反馈是：对不起哥，没有源代码！
我被这个冷酷的回复震惊了，立刻意识到刚才的想法并不是最优解决方案，因为在重新编译的过程中，各种包的依赖关系和编译错误足以让你焦头烂额，我随即提供了 B 计划：在 OS X 上安装 Docker，轻量级的容器 Docker 可以运行各种版本的 Linux，把文件扔到 Docker 里，然后通过主机和 Docker 之间的端口映射即可轻松解决这一问题。
虽然这里面会涉及很多技术细节，但是方向是没有问题的，所以这位程序员立刻表示「茅塞顿开」，然后「biu 」的一声就在屏幕对面消失了，没有留给我说「不客气」的机会。
这个问题装个 Linux 虚拟机也可以解决，但是虚拟机过于耗费资源，而且不如 Docker 灵活，所以不是最佳解决方案。Docker 是。
做为一个程序员，我们除了要掌握多门程序语言和多种数据库，了解前端技术、后端技术，通晓网络七层架构，知道 TCP/IP三次握手和四次挥手，编写漂亮的代码，设计优美的架构……之外，我们还要解决研发、程序运行和产品上线过程中遇到的各种问题，而且被要求以最小的代价来解决问题……我们容易吗？
除了编程技巧和程序设计能力，解决问题的稳准狠是衡量一个程序员是否优秀的重要因素之一，也是资深技术人员真正的价值所在。在科技浪潮澎湃、技术信息扑面而来的今天，一位刚毕业的大学生如果足够勤奋，他可以在两三个月之内掌握一门编程语言，并编写出像模像样的软件，他们的学习速度甚至超过了我们这些老程序员，但是解决问题的能力是无法速成的，只能依靠时间、经验和惨痛的教训历练而成。有时候还需要灵感和运气。
很多军迷读了大量的军事著作和历史小说，常常羡慕那些名将的风采，并浩叹自己「生不逢时」。但是名将不是那么容易炼成的。历史上叱诧风云的名将凤毛麟角，他们亲自持刀上阵追击敌人，见识战场的惨烈，目睹敌人的尸体，看到战友被杀，知道被刀看中会流血死去，他们冷酷无情，坚如磐石，在全军即将崩溃的时候发现敌人的弱点并进行攻击，在瞬息万变的战场进行决断，在多次失败后从无数士兵的尸体里站起来重新出发去挑战那个战胜你的对手，在所有人对你说「指导员，我们上吧」的时候，坚定的说出那三个字：再等等！
如果你做不到这些，那还是做个最终会被张飞枪挑的小兵吧。
优秀的程序员同样如此，菜鸟常常羡慕高手在谈笑之间让难题灰飞烟灭，而自己却苦苦思索而不得入门之法，殊不知这些高手同样经历了名将的那些腥风血雨。他们在清晨的微光里编写代码，在轰鸣的机房中调试程序，他们彻夜不眠就是为了解决一个 bug，他们要承受数据丢失或上线失败的痛苦，默默吞下眼泪，准备下一次的战斗。不停的学习、实践和思索，成千上万个小时之后，高手史成。
同样的问题，高手的解决思路和小球是截然不同的。一般来说，只要不是世界难题，给足时间、空间和人力，都能解决。如果你遇到问题告诉上级，这个问题交给我了，两年之内搞的妥妥哒，那就不要怪项目组组团把你打出翔来，因为大家要的是分分钟解决，不是两年。在这个唯快不破的年代，我们没有这么多的时间，所以要通过逆向思维、经验教训、辗转腾挪、借力打力等方式以最小的代价快速解决问题。这才是老程序员的价值。
再举个例子，一个运行良好的线上应用在你修改 bug 增加功能之后重新上线出现了一些莫名其妙的问题，比如占用资源增加或运行一段时间宕机等等，怎么解决？
常规的做法就是通过阅读日志、模拟线上环境和调试程序来定位错误。容易的 bug 用这些方式基本就能搞定了，但是更隐蔽的 bug 会耗费大量的时间和人力。更好的方式是什么？
首先，排查是程序问题还是环境问题，把线上程序恢复到运行正常时的老版本，如果出现了同样的问题，那就是生产环境发生了改变。如果运行正常，要么是你修改老 bug 时引入了新 bug，要么是新增加的代码出现了问题。
其次，阅读产品的 changelog，根据代码提交的时间线构建系统，通过二分法排查，定位是哪部分代码引起的问题。
第三，排除了所有的不可能，剩下的无论看起来如何不可能，就是它干的。
以上只是一个简单的例子，实际的情况可能比这个例子复杂一百倍，需要我们综合使用各种方式进行交叉比对和错误排查才能解决。这仅仅是遇到问题解决问题，更多的时候是需要你提出问题，并解决问题，那是更高的境界。
很多人学了那么多编程语言，写了十几年程序，最终依然无法做到以最小的代价解决问题，不禁让人扼腕叹息。
程序员真正的竞争力是什么？以最小的代价解决问题！知行合一，方可无敌于天下。
-------------------------------------------------------------------------------------------------
摘录：
方法论看似是个很抽象的东西，并且的确有一些方法论是抽象到 over-generalized （泛化过度）的地步，然而说实话在实践当中我总是发现（正确的）方法论是再现实不过的东西，比如一个大家都明白的道理是：如果方向走错了，那么做的功就基本全白费了（还有比如“如果方法对头，就能事半功倍，反之可能多走很多弯路”）——然而现实中有多少人能够真正实践这个方法呢？绝大多数人都是只顾解决眼前问题，抓了这头丢了那头，更多人是不知道问题是什么，只管把头脑中能联想到的一个以前类似情况下的类似方案套用上来。以前我总是觉得一个公司里面，CEO/CTO 这样的角色是基本摆设，但我现在不这样想了。在 How 层面把事情做好，做成一个精钻的程序员，那顶多就是能把钳子使好，这样的事情很多人都能做到，熟能生巧嘛。换句话说程序员基本上是去解决一个定义好的问题，去实施一个定义好的方案。然而决策问题就不一样了，决策问题是需要去定义问题是什么，以及权衡最佳方案是什么，不管是决策技术架构还是决策商业策略，都是非常复杂的思维过程，需要综合和权衡大量的信息，这种能力就不是简单楞着头搞下去能练出来的了，很多时候需要抬起头来看，免得只见树木不见森林。
当然，我自己还没能到这个层面，尚需要不断实践和总结，所以只能稍微的谈一点感受，再往下扯只怕就会流于空泛了。这一点上我还是举一个程序员们喜闻乐见的例子吧，在程序员眼睛里面，做一个项目，也许首先想到的是用什么语言，什么框架，什么库，在这个方向上那就是什么看上去牛B用什么，恨不能都用 haskell、lisp 来写才爽，用 Java？那多没意思啊，Java 那坨弱智语法我小学的弟弟都能掌握，也没啥牛B的语言特性，忒没成就感（只可惜真正判别弱智与否的并非用什么语言技术，而是做出什么产品满足什么需求）。这就是属于只考虑单个孤立因素的简单（或者说 Naive 的）决策，这个因素就是——只要让我自己感觉爽——只可惜并不是让自己感觉爽的做法就是真正解决问题的做法，始终要弄清问题是什么，在后者意义上，一些对于技术型程序员往往没有吸引力的话题其实有着极其重大的价值——比如什么时候设计，什么时候重构，什么时候集成，再往上一层其实这些又都是次级问题，首要的问题还是这个产品满足什么需求，有什么市场（即这件事情值不值得做），有一句话想必很多人常听说，如果不知道要做什么，套上十二层架构也无济于事，方法永远不是因，而是果。
再举个例子，如果我想给我的网站做一个 feature ，我认为这个 feature 技术上很牛很强大，而且刚好有机会使用一下我最近修炼的某某 framework 和某某语言，而且这玩意很有挑战性，还不是一般人能够做得了的，综合以上三点，我立时觉得心痒难耐摩拳擦掌。然而实际上这个问题应该怎样分析呢？首先，考虑到以上三点，这将会是一个投入相当大的项目，那么其收益就必须要对得起这个投入，技术上很牛不代表商业上就牛，再牛再难做的 feature 如果不能带来商业价值那就是负收益。总而言之，
1. 一件事情仅仅让你感觉挺牛不代表这件事情就是值得做的； 2. 一件事情仅仅让你感到很有兴趣并不代表这件事情就是值得做的。
====================================================
什么才是你的不可替代性和核心竞争力 BY 刘未鹏 摘录：
我虽不是经济学专业，但是翻开任何一本经济学的教材，或者直接翻开 wikipedia 的 economics 条目，都会看到物以稀为贵这条铁律。人才作为资源的一种，也是同样的道理。而稀缺性，换种说法也可以叫做不可替代性。一种资源越是稀缺，不可替代性就越强。再加上如果这种资源是一种具有实实在在使用价值的东西（而不是荷兰的郁金香泡沫），那么其价格就会越高。
问题是，如何构筑你的个人知识体系，使得你的知识技能集尽可能成为不可替代的呢？我相信以下的知识技能组合是具有相当程度的不可替代性的：
- 专业领域技能：成为一个专业领域的专家，你的专业技能越强，在这个领域的不可替代性就越高。这个自是不用多说的。
- 跨领域的技能：解决问题的能力，创新思维，判断与决策能力，Critical-Thinking，表达沟通能力，Open Mind 等等。
- 学习能力：严格来说学习能力也属于跨领域的技能，但由于实在太重要，并且跨任何领域，所以独立出来。如何培养学习能力，到目前为止我所知道的最有效的办法就是持续学习和思考新知识。
- 性格要素：严格来说这也属于跨领域技能，理由同上。一些我相信很重要的性格要素包括：专注、持之以恒、自省（意识到自己的问题所在的能力，这是改进自身的大前提）、好奇心、自信、谦卑（自信和谦卑是不悖的，前者是相信别人能够做到的自己也能够做到，后者是不要总认为自己确信正确的就一定是正确的，Keep an open mind）等等。
相关： 产品经理的核心竞争力是什么？为什么？ http://www.zhihu.com/question/27523939 产品运营的核心竞争力是什么？为什么？http://www.zhihu.com/question/29125999
