好的程序员到底好在哪里？

我这些年和许多程序员工作过——他们有些人超级棒，有些明显比较平常。因为我近来和一些熟练的程序员工作的很愉快，我花了一些时间考虑我羡慕他们什么。是什么让一个好的程序员那么好，差的程序员那么差?或者，简短一些，是什么让一个好的程序员那么好呢?

根据我的经验，成为一个优秀的程序员与年龄、教育或者你挣钱的多少没有关系。关键在于你的表现，更深刻的说，是你如何思考。我注意到我羡慕的程序员有一致的习惯，比起他们所选语言的知识、对数据结构和算法的深入理解、或者几年的工作经验——更多的是他们交流的方式，管理自己的方式，和根据他们精湛的技巧可以知道他们接触编程的方法很有意义。

当然，成为一个好的程序员需要的比任何人可以列举的都还要多，我不会基于这些实践的存在(或者缺失)而单独评判任何程序员。但当我看到时我确实能明确的知道，当我看到一个具有这些性格的程序员时，我会想，“这个人真的知道他们在做什么。”

他们做研究

或者称作“三思而后行”，或者称作“谷歌一下”。

无论你怎么称呼它，你可能遇到的大多数编程问题几乎在一定形式上都已经被解决了。传道书早就记录在案，阳光底下无新事。在GitHub上的库文件列表中，在因特网上的博客中，或者恰好与某个人经验交流中，好的程序员知道要在解决一个问题之前先做研究。

我曾经见过伟大的程序员急于给出解决方案，但是我曾经一起工作过的最糟糕的程序员，从来不咨询他人，从而导致做了大量的重复性工作或者恰好使用了错误方式来解决问题。于是很不幸的，他们最终为他们的错误付出代价。

读错误信息(并以之行事)

这包括对堆栈追踪的符号解析。是的，令人厌恶而且不幸——但如果你不愿意这么做，怎么知道哪里出错了?我知道的最高效的程序员不害怕深入挖掘问题。最低效的程序员看到错误甚至都不愿读错误信息。(这听起来挺可笑的，但我遇到的频率会让你吃惊。)

更进一步说，伟大的程序员看到问题，会急迫的去解决它。对于他们来说，读错误信息仅仅是第一步;他们渴望深入问题并找出错误的根源。他们对推卸责任没有兴趣，他们对找到解决方案有兴趣。问题确实在他们这里止步。

他们会去看源代码

文档，测试和人：这些都可能会说谎。未必是故意撒谎，但是如果你想确切的知道代码是怎么工作的，你就必须亲自察看源代码。

即使这不是你非常熟悉的语言也不要害怕——比如，如果你主要是一个Ruby程序员并且你怀疑Ruby的C语言包里有错误，那就去解压它看看再说。不错，你可能会一无所获。但是谁知道呢，你也可能会找到问题所在，比起什么都不做，你至少选择了一条更有机会的路。

如果你工作在一个非开源的环境中，就不太好办了，这很不幸，不过道理是不变的。糟糕的程序员对查看源码通常没有太多兴趣，结果就是，跟那些愿意去研究一下源码的人相比，他们通常会被这些问题困扰的更久。

他们说做就做

好的程序员总是趋向于采取行动。他们似乎有种控制不住的强迫性——一旦他们确认了一个问题或者看到了一个新的特性需求，就会立即着手解决，有时甚至过早或者过于勇往直前。他们遇到问题的直觉反应就是正面解决它。

有时这会带来麻烦——但是他们的热情正是他们能够做的很好的关键因素。当某些人还在拖延回避或者幻想问题能自己消失的时候，好的程序员已经开始动手了。

更简单的来说(也许，太过直白)，如果你看到一个人兴奋的发现并处理问题，很有可能你得到了一名好程序员。

他们防患未然

这可能是一个坏的程序员的特征——他们总是纠缠于一个又一个的人为失误，从来都是没有明白上一个就转向下一个。他们总是在抱怨他们程序中的错误部分，却耗费数小时对完美运行的代码来debug。他们让情绪占据主动，相信直觉而不是仔细明确的分析。

如果你突然遇到一个问题——或者每一个问题看起来都像是世界末日一般，你极有可能是在犯错误而不是在解决潜在的问题。伟大的程序员会花费一些时间来了解是什么出了错，哪怕是真的是一场灾难，除了这些，他们还会把常出现的问题当成分配任务来处理掉。由于他们能更精确的解决大部分问题，从而不会提高你的团队的紧张程度。

他们善于交流

说到底，编程也是一种交流的方式。能够简洁明了地表达出你的观点之于写代码就如其之于写诗一样重要——长久以来，我发现那些能够写出精炼的电子邮件、优雅的报告或者仅仅是高效的备忘录的人通常也会是更优秀的程序员。

这个发现对写程序和对英语一样使用。当然，把充斥着括号和只用一个字母命名的函数写在一行里面也是可以的，但是如果没有人能够理解你写的代码，又有什么意义呢?无论使用什么媒介，优秀的程序员会把时间花在如何将他们的观点更好地表达出来上面。

他们激情四射

我想这是最能够体现一个好的程序员的地方(并且，不仅在计算机行业，这点适用于任何行业)。