我这些年和许多程序员工作过——他们有些人超级棒，有些明显比较平常。因为我近来和一些熟练的程序员工作的很愉快，我花了一些时间考虑我羡慕他们什么。是什么让一个好的程序员那么好，差的程序员那么差？或者，简短一些，是什么让一个好的程序员那么好呢？
根据我的经验，成为一个优秀的程序员与年龄、教育或者你挣钱的多少没有关系。关键在于你的表现，更深刻的说，是你如何思考。我注意到我羡慕的程序员有一致的习惯。比起他们所选语言的知识、对数据结构和算法的深入理解、或者几年的工作经验——更多的是他们交流的方式，管理自己的方式，和根据他们精湛的技巧可以知道他们接触编程的方法很有意义。
当然，成为一个好的程序员需要的比任何人可以列举的都还要多，我不会基于这些实践的存在（或者缺失）而单独评判任何程序员。但当我看到时我确实能明确的知道，当我看到一个具有这些性格的程序员时，我会想，“这个人真的知道他们在做什么。” 他们做研究
或者称作“三思而后行”，或者称作“谷歌一下”。
无论你怎么称呼它，你可能遇到的大多数编程问题几乎在一定形式上都已经被解决了。传道书早就记录在案，阳光底下无新事。在GitHub上的库文件列表中，在因特网上的博客中，或者恰好与某个人经验交流中，好的程序员知道要在解决一个问题之前先做研究。
我曾经见过伟大的程序员急于给出解决方案，但是我曾经一起工作过的最糟糕的程序员，从来不咨询他人，从而导致做了大量的重复性工作或者恰好使用了错误方式来解决问题。于是很不幸的，他们最终为他们的错误付出代价。 读错误信息（并以之行事）
这包括对堆栈追踪的符号解析。是的，令人厌恶而且不幸——但如果你不愿意这么做，怎么知道哪里出错了？我知道的最高效的程序员不害怕深入挖掘问题。最低效的程序员看到错误甚至都不愿读错误信息。（这听起来挺可笑的，但我遇到的频率会让你吃惊。）
更进一步说，伟大的程序员看到问题，会急迫的去解决它。对于他们来说，读错误信息仅仅是第一步；他们渴望深入问题并找出错误的根源。他们对推卸责任没有兴趣，他们对找到解决方案有兴趣。问题确实在他们这里止步。 他们会去看源代码
文档，测试和人：这些都可能会说谎。未必是故意撒谎，但是如果你想确切的知道代码是怎么工作的，你就必须亲自察看源代码。
即使这不是你非常熟悉的语言也不要害怕 – 比如，如果你主要是一个Ruby程序员并且你怀疑Ruby的C语言包里有错误，那就去解压它看看再说。不错，你可能会一无所获。但是谁知道呢，你也可能会找到问题所在，比起什么都不做，你至少选择了一条更有机会的路。
如果你工作在一个非开源的环境中，就不太好办了，这很不幸，不过道理是不变的。糟糕的程序员对查看源码通常没有太多兴趣，结果就是，跟那些愿意去研究一下源码的人相比，他们通常会被这些问题困扰的更久。 |
