有个问题就很有意思：

“程序员们看同一个问题，有些人就能抓住重点，有些人就是不能。有时候还和经验不成正比。你怎么看？”

关于这个问题，有很多感触和想法，比较乱，我试着理理清楚。

一

透过现象看本质，仅仅聪明是不够。横着说，你需要对整个事情的全局情况有了解。在发生问题出现 bug 去解决的时候，你知道的越多，能想到的可能相关的原因就比较多，然后根据 bug 的现象，一一对应，排除不能解释症状的猜测，知识越渊博，你能一眼找到问题所在的概率就更大。如果知识就是不够，任你想破脑袋，可能问题出在你不了解的一个地方。

纵着说，所有事情都是动态的。如果一个问题的发生，或是一个决定的成败归咎于一个历史因素，那知道那件事的人就有更多的信息做判断。举个例子，我们在系统出问题的时候，有一类问题是突然从某一天某一个时刻开始出现，那么去看看那个时间有没有人改动过什么代码，改动过什么配置，访问量有没有突变……就极大可能能找到起因。

很多系统设计也是如此。往往有些新人，会吐槽这个系统怎么设计成这样。会这样说的，或者就是极牛的，或者就是极弱的。试想哪个系统不是一点点进化出来的。有一些系统其实是在公司只有十几个工程师的情况下搭出来的。你觉得哪个公司一开始的系统就设计的几千个人可以同时在这个代码库写代码，可以同时支持几亿个人，几百种不同的使用场景？有些系统的问题，放到当初做系统的那个时间去看，才能有比较合理的评价。

而这两点，除了需要有比较强的逻辑思维去联系因果，大量的知识是必不可少的。所以就像一万小时定律说的，成为专家，总是要付出很多的时间，包括吸收和消化各种信息。

二

关于是不是和经验成正比。

不一定。这就涉及到有些人的类比的能力。

一套高考模拟题，有些人，做个两三套，然后不管题目怎么变，几乎都能考个满分。有些人，做了十几套，题目稍微变点样，就又不会做了。

有一个同事，以前是学法律的，最近转行写代码，写出的代码比很多写的年份多得多的人还强的多。她对法律相关的思维的缜密，很好地就转移到了代码逻辑的缜密上，不学自通。

很多读研究生的朋友，一入职场，就会给一个比较高的 Level。你说他研究的题目和做的工作有相关么？并不是。不过受过一些独立解决问题的训练，而这种训练，很多时候可以转换成对另一个完全不同的问题的思维和方法。

初入职场的时候，我心里也默默害怕过：哎呀，我没学过 C# 怎么办？我也不懂 Rails 怎么办？但是经历几次后，再去找工作的话，我根本不关心这个公司会用哪种语言，哪些工具。没用过，也能很快学通。很多基本的东西，是一样的。

三

就算你知道的多，你能给对方带来多大的帮助，是不是让别人觉得你一语解惑，还局限于你交流和沟通的能力。

换位思考。每个系统，每个问题，都有很多方面。当别人看起来比较疑惑的时候，你给他/她一本《用户使用手册大全》，往往没有一本《常见问题解答》，你给他一本《常见问题解答》，可能没有 Stack Overflow 上一个针对问题的帖子有用。三言两语切入痛点，知道对方疑惑的地方是什么，比劈头盖脑，滔滔不绝，结果重点都被掩没要好得多。

说对方的语言。如果对方是产品经理，试图以产品的语言去解释。如果对方是计算机科班出身，那么简洁地使用计算机术语，直接说理论的名字或者算法的名字就行（如二次握手、Trie、NP 等）。如果对方是外专业转行的程序员，不妨试试直接拿着代码来讲。如果对方完全不是一个行业的，就是着类比到他/她了解的一些问题和知识来解释。

Zoom in 和 Zoom out。实在不知道怎么用中文表达。类似相机、地图、和图片里面放大/缩小的功能。看问题能够 zoom in 到痛点，又能随时自如切换到全局。先定位问题在全局中的方位，解释清楚，再回到全局去理解评估。

四

所有的总结，只有带着问题去思考才会有收获。不论我说多少，如果没有过类似的经验，就很难有很强的共鸣。我觉得看清一个问题最好的方式，就是你曾经处在一个问题的两个不同的角色中：

当你去问一个老人很多问题的时候，虽然可能你能很快得到解答，似乎也没有花别人很多时间。然而有一天，你自己熬到有很多新人问你问题的时候，你就能体会到什么问题该问，什么问题不该问。

当你写自己的代码的时候，别人给你提的意见，你可能觉得很好，也可能觉得很烦。等有一天你去读一段晦涩难懂的代码的时候，你才能理解为什么有些看似细节会那么重要。

我也曾站在一个位置，去向别人请教，别人告诉我：“这个问题，从本质上来说，它就是……” 一下子觉得豁然开朗。也有别人在想一个问题，我站在给建议的角度，一下子说到关键点。其实就是一个成长的过程。努力，用心，思考，这些都需要时间的积累。但如果不用心，时间花的更多些，也不会有太大的进步。