高效程序员的 7 个共同特征（Seven traits of effective programmers）
翻译文地址：http://www.oschina.net/translate/seven-traits-of-effective-programmers
导读：要想成为一个伟大的程序员，需要的可不仅仅是能够编写出可以正常运行的代码。Justin James给出了能够成为业内顶尖高手的程序员应该具有的几个典型特质。
要想成为高效的程序员，你需要具备一定的综合素质才能够让你用你所掌握的技能、经验和知识编写出有效的代码。有一些开发人员在技术方面具备一定的技巧，但他们永远无法成为高效的程序员，就是因为他们缺乏所需的其它几项特质。本文将给出成为一个伟大的程序员所必须具备的7项特质。
1. 主动学习新的技术和非技术两方面的知识
不好的程序员只有在实在不行的时候才开始进行知识学习。良好的程序员会主动学习新的技术知识。伟大的程序员不仅会自行学习新的技术知识， 而且还会学习非技术方面的知识，对各种知识来源都有一种开放的心态，而不会象有的人那样固步自封。
具体点说，不好的程序员只有在参加了采用WPF的项目时才开始学习XAML；良好的程序员一年前就学习了XAML，因为他感觉它很有意思；而伟大的程序员还阅读了WPF应用程序的设计指南、可用性（usability）理论或者什么类似的学习课程，因而他能够制作出卓尔不群的UI。
2. 务实而不教条
严格遵守那些不成文的“编程规则”往往是一种奢侈品，没有多少开发人员能够承受得起。如果你们的规格说明书不是由顶尖的开发人员编写的，也不是在顶尖的开发人员指导下编写的， 我就可以向你保证，你可能也承受不起。
我经常能够碰到一些程序员，他们无法或者拒绝做某个任务只是因为完成这个任务的做法通常不为最佳实践所接受。业务需求很少会受到实现需求所采用的技术的制约；没有人会说，“这我们不应该把这个需求写到规格说明书里，因为要实现这个需求，程序员就不得不写一段很臭的代码。”
在结束的那一天，程序员的任务是要生成一个有效的应用程序，而绝不是要求在技术方面达到十全十美。我可不是在为垃圾代码做辩护。我想说的是，总会在有些时候，你会写出一些代码，这些代码你永远不会作为范例向别人展示做事的正确方法。如果只有一种写法，那么这种代码就不是糟糕的代码 —— 但要保证你已穷尽了其它所有可能的方案。
3. 懂得如何通过研究找到答案
通过研究找到答案可不仅仅只是在搜索引擎中键入几个关键字那么简单， 也不是到Stack Overflow或者MSDN forums这类网站发个问题帖。我就碰到过在搜索引擎里根本搜不到答案的问题，然后我Stack Overflow 或者MSDN forums里发的所有问题贴都没有一个像样的答案，不过我还是解决了我所碰到的问题使得工作得以继续。我不是魔术师 —— 我只是懂得如何找到答案，如何找出问题的根本原因。
有许问题都属于情景式的问题，如果你依赖于搜索引擎或者论坛，就会在各种链接中浪费大量的时间而最终无法得到真正的答案。要学习如何进行根本原因分析，学习底层系统方面的知识才能够找到其它的线索和解决方案，还要学习如果在对问题有个全局性的认识后才对其进行深入分析。
4. 拥有激情
不喜欢这份工作，就无法成为这个行业中的顶尖高手。倒是也有一些仅仅把编程当作一份普通工作的程序员水平也还不错，但如果你的三观就是如此的话，你就不太会愿意去做能够将你引向成功的所有事情。这个观点会使很多家伙不悦，因为他们会觉得这是一种人身侮辱。“我是一个很好的程序员，但我还有其它重要的事情要做，我不能让工作成为我人生的全部。” 我完全理解；我也有别的更重要的事情。尽管我也痛恨这么说，当我们对我的工作热情高涨之时，我愿意（虽然不是渴望）抛弃我其它更重要的事情来首先完成手头的工作。要说你不愿意全情投入就无法成为高手，不算是人身侮辱，这是事实而已。
你的激情不能仅仅只在编程一个方面 —— 你必须在你的工作、你所使用的技术、你的老板、你的项目等等方面都有激情。 我目睹过一些非常好甚至很伟大的程序员其表现平平，只是因为有一些条件不太合适。比如，他们不喜欢手头的项目，或者项目中所用的技术让他们讨厌。我曾经就是一个这样的程序员，我也同这样的程序员一起共过事。无论从哪个角度讲，我都不喜欢这样的程序员。如果你发现你的情况就是如此，就需要立即解决这个问题，要么挖掘出手头的工作或项目中有意思的地方从而能让你调整心情，要么就不要接着干了。怪不值当的。
5. 将自负留在门外
许多开发人员都非常自负。仅仅是比有些人聪明、懂得多一点或者经验更丰富一点，可不是意味着和那些人相比你才是好人。你要尊重别人，真正听取并考虑别人的观点，在需要的时候向他们求助，而且还不能小瞧别人。 你还应该更加关心团队的胜败，而不是仅仅关心你在工作中的荣誉得失。
6. 具有企业家的精神
最优秀的开发人员不会是游手好闲者。对他们来讲，产品的成功不仅仅意味着他们的薪水有着落了。因为他们在工作中热情饱满，他们是为了项目有更好的发展而工作，而且会一往无前。
7. 测量两次，下刀一次。。。但测量不要多于三次
开发人员可能会犯的最糟糕的错误之一就是还不知道要干什么呢，就一猛子扎到代码里去了。（当他们把这种做法称作敏捷开发时情况更为糟糕，好像用敏捷两字就能让情况好转似的）。当伟大的开发人员跳进代码里去的时候，那是因为需求规格说明同他们以前实现过的某种做法十分相似。伟大的程序员在面临新问题时，他们会进行思考、计划和研究。
开发人员当中最最优秀的不会堕入“分析瘫痪者（analysis paralysis）”陷阱。他们懂得要对某些事情小心谨慎（比如涉及钱或个人数据时），只有这些特殊领域才适合我所说的“要测量三次”。任何超过三次的情况发生就意味着你在浪费你的时间（除非在鲜有的特例中，比如核反应堆、宇宙飞船、对冲基金会计系统）。
在某个特定的时间点就要停止计划，开始编码，然后再看看你的计划在哪些方面需要进行相应的调整，这一点非常重要。顺便说一下，这就是我为什么成为敏捷方法拥趸的原因之一。我所知道的最优秀的开发人员在计划不再合适或者发现计划有缺陷时，都会愿意将计划放弃掉。
Takeaway: Being a great programmer involves more than writing code that works. Justin James lists the hallmarks of programmers who rise to the top ranks of their profession.
In order to be an effective programmer, you need to possess a combination of traits that allow your skill, experience, and knowledge to produce working code. There are some technically skilled developers who will never be effective because they lack the other traits needed. Here are seven traits that are necessary to become a great programmer.
1. Learn new tech and non-tech skills of their own accord
Bad programmers only learn things when it’s absolutely necessary. Good programmers learn new technical skills proactively. Great programmers not only learn new technical skills on their own but also learn non-technical skills, and have an open mind to sources of knowledge that others may shut out.
To put it in concrete terms, the bad programmer learned XAML when they started a project using WPF; the good programmer learned it a year before because it looked interesting; and the great programmer also read about the design guidelines of WPF applications, usability theory, or some similar course of study so they could make exceptional UIs.
2. Are pragmatic, not dogmatic
Rigid adherence to the unwritten “rules of programming” is usually a luxury that very few developers can afford. I can almost guarantee that if your specs are written by or influenced by someone who is not a top developer, you are not in this group.
All too often, I encounter programmers who cannot or refuse to do the work because the answer is not in the list of commonly accepted best practices. Business requirements are rarely constrained by the technical consequences of implementing them; no one is going to say, “maybe we shouldn’t include that in the spec, because the programmer will have to do something that has a bad code smell to it.”
At the end of the day, the programmer’s job is to produce a working application, not technical perfection. I am not advocating writing garbage code. I am saying there will be times you will write code that you would not show someone else as an example of how things should be done. It’s not bad code if there’s only way to write it — just make sure you have exhausted your other possibilities.
3. Know how to research for answers
Researching for answers means more than typing several keywords into a search engine or posting a question at Stack Overflow or the MSDN forums. I have entered problems into search engines that generate no results, and every question I posted on Stack Overflow or the MSDN forums never got anything resembling an answer, yet I solved the issues and moved on. I’m not a magician — I just know how to find answers or discover root causes.
Many problems are situational, and if you depend on search engines and forums, you can waste a lot of time going down a rabbit hole and possibly never getting a solution. Learn to perform root cause analysis, learn enough about the underlying system to look for other clues and solutions, and learn to take a long distance view of an issue before deep diving into it.
4. Have passion
You cannot rise to the top in this profession without loving the work. There are some very good “it’s just a job” programmers (I’ve been one at times), but if that is your outlook, you won’t be willing to do whatever it takes to succeed. This idea gets a lot of folks in a huff, because they feel it is a personal insult. “I’m a good programmer, but I have other priorities and can’t make work my life.” I understand completely; I have other priorities too. As much as I hate to say it, when I am passionate about my work, I am willing (though not eager) to abandon my other priorities to finish the job. It is not an insult to say that if you aren’t willing to pull out all the stops you can’t be the best, it is a fact.
You must be passionate about more than programming — you must also be excited about your job, the technology you are using, your employer, your project, and so on. I have seen very good and even great programmers operating at mediocre levels because something was not a good fit, such as they hated the project or were using a technology they disliked. I have been that developer, and I have worked with that developer, and I don’t like it from either side of the fence. If you find yourself in that situation, you need to address it immediately by discovering something about the job or project to get psyched about, or get out of there. It’s not worth it.
5. Leave their egos at the door
Many developers have huge egos. Being smarter, more knowledgeable, or more experienced than someone else does not mean you are better than that person. You need to treat people with respect, listen and truly consider another person’s ideas, ask for help when needed, and don’t look down on anyone else. You should also care more about whether the team succeeds than if you get credit for your work.
6. Have entrepreneurial spirits
The best developers are not drones. They have a true sense of entrepreneurship and feel ownership in the product. To them, the product’s success means more than just the continuation of their paychecks. Because they have emotional skin in the game, they work for the good of the project, and go the distance.
7. Measure twice, cut once… but do not measure more than three times
One of the worst mistakes a developer can make is to dive headfirst into code without any idea of what they are doing (it’s even worse when they call this Agile, like trying to paint it as Agile makes it better). When great developers jump into coding, it is because the specs are very similar to a pattern they implemented before. When great developers are confronted with a new issue, they think, plan, and research.
The best of the best developers do not let themselves get sucked into the “analysis paralysis” trap. They know to be more cautious about some things (e.g., anything that touches money or personal data), which is why I say it is fine to “measure three times.” Anything past three times, and you are just wasting your time (there are very rare exceptions, such as nuclear reactors, spacecraft, and hedge fund accounting systems).
It’s important to stop planning after a certain point and start coding, and then see where you need to adjust your plans. Incidentally, this is one reason why I’ve become a big fan of Agile. The best developers I know are willing to sacrifice a plan if the plan is no longer suitable or is discovered to be flawed.