今天心血来潮，思考如何成为一个牛逼的程序员，他们有什么特质？扪心自问，这些特质自己有没有，差距在哪里？下来先搜索看下这些牛人有哪些特质,以下是来自知乎的一些观点，请认真看完，深思！
---------------------------------
如何成为杰出的程序员或软件工程师？
85 个回答
原作者： Nick Dellamaggiore, 基础架构组工程经理
2015年2月3日
作为一名工程经理，我经常被同事和面试人问“作为一个Coursera工程师，我的职业生涯发展是什么？”尽管有些人更希望成长为经理，但我发现还有很多人对如何成长为独立贡献者（ individual contributor）更有兴趣。
所有在Coursera工程师共享同样的名称：“软件工程师”。你可能会认为这会导致模糊的职业发展，但我们相比严格的等级，更喜欢这种模式，理由如下。
我们是一个小的，紧凑的工程组织下的创业公司，我们专注于一起工作，共同实现我们的使命：为全世界提供最好的教育而奋斗。每个人在没有被人为组织结构，职称和角色所羁绊下去发挥其最大的潜能。
我们的文化体现着谦逊。杰出的工程师认可是被公认的贡献，领导力和态度，而不是他们的头衔。
每个人都是领导者。我们的文化是非常开放的，包容的;一些最好的想法，往往来自刚毕业大学生或实习生。我们渴望帮助每个人在这里成长为技术带头人。
作为技术人员，我们正不断努力改善我们的技能，帮助我们的工程师不断提高。我们希望在这里的工作，是我们自我变革的体验，并以同样的方式去改造公司的轨迹。
为了指导我们的工程团队，我们列出由一些杰出高产的工程师都体现的品质列表。这些都是我们在Coursera，以及其他硅谷高科技公司同行，如LinkedIn，谷歌和Facebook所钦佩的优秀素质。我们分享这个列表，并希望激发其他工程团队去思考他们看重的素质，以及如何建立，培养和奖励优秀人才的企业文化。
如何成为一个伟大工程师
结果驱动
伟大工程师产生了伟大成果。 Coursera重视工程师从开始设计，实施到交付一系列环节。这里的原因：
对于任何重大项目，往往是在细节中出问题。比如产品推出，运营服务，产品功能。在交付和运营的服务或产品上体现主人翁意识，这是我们的核心价值观。
结果会直接给业务增值。我们认为一个员工的贡献累计来自于如何衡量增加的价值。影响力可以来自于很多维度，包括增值，活跃度，收入，工程效率，网站稳定，可扩展性等等。显著影响力在交付MVP（最小核心价值产品）很少能够实现。在我们搭建的产品和需求中不断的迭代才能最大化我们的价值。
我们的指导方针是“有效爬坡”的原则，我们赞赏能够平衡执行速度，编写可扩展组件和代码质量。我们也看重“10倍工程师”，即不仅能快速提供高质量的结果，同时也激励和指导别人更聪明地更快的工作。
领导力
领导者不一定是一个管理者。技术领导是说的你的工作方式。你把你的项目，团队，整个技术组服务好。最好的工程师显示至少其中的一些特质：
项目领导：伟大的工程师们可以从不同的项目中担任技术负责人的角色，项目的范围从小到大，影响力从低到高。他们能驾驭好点子，阐明设计，排除阻碍，不断改进。他们跟产品组合作确立正确的产品上线顺序，他们知道在质量，完成度和速度如何权衡考虑。有时他们通过数据驱动决策保证项目完成。
找出差距：伟大的工程师们能够广泛地思考面临的差距和问题。更重要的是，他们是第一次去发现我们从来不知道我们有的问题。他们更看重解决问题而不是抱怨 - 事实上，他们渴望保持手勤，用创造力和真正的热情应对面前的挑战。
“向上看齐”：伟大的工程师们往往围绕比他们更好的工程师。他们是以身作则提高生产力，领导和激励他人。他们通过代码和设计评审来作为导师帮助大家。
爱学习：伟大的工程师为了不断提高技能，他们热情地阅读技术文档，研究论文，和博客。他们喜欢上课，吸收别人的经验。
组织存在感：伟大的工程师在整个组织中传承知识和经验。他们通过技术讲座，读书分享，Hack大赛去分享他们的工作。一个伟大的工程师可以在外部发表博客文章，会议演讲，或发表研究论文。
影响力：伟大的工程师影响其他工程师采用新技术，架构，流程和标准。这可以通过他们能影响到的工作空间距离或者代码审核队列的大小来衡量。
态度：像所有Coursera的员工，优秀工程师们关心队友和保持谦卑。他们认识到，每一个错误其实是有机会让他们做的更好。
技术卓越
伟大的工程师在技术上的优秀体现在很多方面：他们可以是厉害的产品黑客，算法高手，注重细节的基础架构工程师，或以上所有。我们重视在设计解决方案时深入思考，考虑复杂的产品和基础设施问题的工程师。
伟大的工程师设计是强大的，直观的，可扩展的，灵活的，可维护，可操作性，可扩展性和高效的。他们努力质量和执行速度之间实现平衡。
权衡
除了业务目标的贡献，伟大的工程师通过提高工程团队的工作效率，构建可重用的组件，提供工具，使代码库更好管理这些都能整体性提升工程组织。这意味着构建抽象的服务或组件，使它们成为多个产品的需求或提高开发人员的生产力。这也意味着主动去构建工具，提取函数库，修复破碎的窗户，编写工程文档，或测试用例。
这不是一个清单！
伟大的工程师不一定擅长在上面列出的所有领域，但必须擅长一些。他们可能是非常全面的，或者在少数项目上极其突出。像下面的游戏人物，你不大可能就像塞西尔（左）全面高分;但你可能更像哥拉斯（右）更加均衡。
在Coursera我们怎么使用这个列表？
我们在内部表扬一些体现了这个标准中可以表率的工程师。
独立贡献者使用这个文件来追踪他们事业上的进步，我们都添加注释，故事和例子，以便其他人可以了解谁做了了不起的事情。
在Coursera工程经理使用此文档对团队成员在1：1会议，和绩效考核中去反馈评价。
任何人当他们看到其他人做很棒的事情都可以直接说出来。这可以在发生在 1:1 (两个人的会议)，全组大会，技术部大会，通过Slack频道（企业通讯工具），或通过电子邮件。
最后的话
在Coursera，我们为全世界提供最棒的教育资源。我们想把高质量的教育，不再只提供给精英，而是公平的环境。同样，在我们的工程组，我们想创造一个让每一个工程师能够实现伟大的环境。我们提倡透明制度和包容性，并提供质量为导向的这份列表，来帮助工程师继续改进。
成为杰出程序员，意味着你将获得诸多 自由：
财务自由，时间自由，心灵自由。
谁不向往自由——
然而， 自由的一面是必要的约束，比如下面你会读到的软件工程师能力自我评价表（ 37条）。
软件工程的奠基人之一瓦茨.汉弗雷总结说，软件领域可以分为两个方面：一方面是技艺创新的大爆发；而另一方面是坚持不懈的工程工作，包括软件的改善、维护和测试等，这一方面占了90%-95%的比例。（详见 软件故事 第三章） 绝大部分软件工程师都不是技术天才，但却都可以通过坚持必要的约束（训练），成为杰出的程序员（软件工程师）。
最近我们出版的这本书 构建之法——现代软件工程得到诸多好评，比如：
请看： 《构建之法》试读 （多看版已上线：构建之法【下载 在线阅读 书评】）
书中第三章的主题是“ 软件工程师的成长” ，作者邹欣老师结合中国软件行业的特点，归纳出在中国IT行业“好工程师”的要素，并做成一个自我评价清单：
现代软件工程 课件 软件工程师能力自我评价表（37条）
1.保持高标准，不要受制于破窗理论(broken windows theory)。
当你看到不靠谱的设计、糟糕的代码、过时的文档和测试用例的时候，不要想“既然别人的代码已经这样了，我的代码也可以随便一点啦。”[i]
2. 主动解决问题。当看到不靠谱的设计，糟糕的代码的时候，不要想“可能别人会来管这个事情” ，或者“我下个月发一个邮件让大家讨论一下”。要主动地把问题给解决了。
[ii]
3. 经常给自己充电，身体训练是运动员生活的一部分，学习是软件工程师职业的伴侣。每半年就要了解和学习一些新的相关技术。通过定期分享（面对面的分享，写技术博客等）来确保自己真正掌握了新技术。
4. DRY （Don't Repeat Yourself）——别重复。在一个系统中，每一个知识点都应该有一个无异议的、正规的表现形式。
5. 消除不相关模块之间的影响，在设计模块的时候，要让它们目标明确并单一，能独立存在，没有不明确的外部依赖。
6. 通过快速原型来学习，快速原型的目的是学习，它的价值不在于代码，而在于你通过快速原型学到了什么。
7. 设计要接近问题领域，在设计的时候，要接近你目标用户的语言和环境。
8. 估计任务所花费的时间，避免意外。在开始工作的时候，要做出时间和潜在影响的估计，并通告相关人士，避免最后关头意外发生。
9. 图形界面的工具有它的长处，但是不要忘了命令行工具也可以发挥很高的效率，特别是可以用脚本构建各种组合命令的时候。
10. 有很多代码编辑器，请把其中一个用得非常熟练。让编辑器可以实现自己的定制，可以用脚本驱动，用起来得心应手。
11. 理解常用的设计模式，并知道择机而用。设计模式不错，更重要的是知道它的目的是什么，什么时候用，什么时候不用。
12. 代码版本管理工具是你代码的保障，重要的代码一定要有代码版本管理。
13. 在debug的时候，不要惊慌，想想导致问题的原因可能在哪里。一步一步地找到原因。要在实践中运用工具，善于分析日志（log），从中找到bug。同时，在自己的代码里面加 log.
14. 重要的接口要用形式化的“合同”来规定。用文档和断言、自动化测试等工具来保证代码的确按照合同来做事，不多也不少。使用断言 (assertion) 或者其他技术来验证代码中的假设，你认为不可能发生的事情在现实世界中往往会发生。
15. 只在异常的情况下才使用异常 (Exception), 不加判断地过多使用异常，会降低代码的效率和可维护性。记住不要用异常来传递正常的信息。
16. 善始善终。如果某个函数申请了空间或其他资源，这个函数负责释放这些资源。
17. 当你的软件有多种技术结合在一起的时候，要采用松耦合的配置模式，而不是要把所有代码都集成到一起。
18. 把常用模块的功能打造成独立的服务，通过良好的界面 (API) 来调用不同的服务。
19. 在设计中考虑对并行的支持，这样你的API 设计会比较容易扩展。
20. 在设计中把展现模块 (View) 和实体模块 (Model) 分开，这样你的设计会更有灵活性。
21. 重视算法的效率，在开始写之前就要估计好算法的效率是哪一个数量级上的（big-O）。
22. 在实际的运行场景中测试你的算法，不要停留在数学分析层面。有时候一个小小的实际因素 (是否支持大小写敏感的排序，数据是否支持多语言)会导致算法效率的巨大变化。
23. 经常重构代码，同时注意要解决问题的根源。
24. 在开始设计的时候就要考虑如何测试 ，如果代码出了问题，有log 来辅助debug 么? 尽早测试，经常测试，争取实现自动化测试，争取每一个构建的版本都能有某些自动测试。
25. 代码生成工具可以生成一堆一堆的代码，在正式使用它们之前，要确保你能理解它们，并且必要的时候能debug 这些代码。
26. 和一个实际的用户一起使用软件，获得第一手反馈。
27. 在自动测试的时候，要有意引地入bug，来保证自动测试的确能捕获这些错误。
28. 如果测试没有做完，那么开发也没有做完。
29. 适当地追求代码覆盖率：每一行的代码都覆盖了，但是程序未必正确。要确保程序覆盖了不同的程序状态和各种组合条件。
30. 如果团队成员碰到了一个有普遍意义的bug, 应该建立一个测试用例抓住以后将会出现的类似的bug。
31. 测试：多走一步，多考虑一层。如果程序运行了一星期不退出，如果用户的屏幕分辨率再提高一个档次，这个程序会出什么可能的错误?
32. （带领团队）了解用户的期望值，稍稍超出用户的期望值，让用户有惊喜。
33. (带领团队) 不要停留在被动地收集需求，要挖掘需求。真正的需求可能被过时的假设、对用户的误解或其他因素所遮挡。
34. （带领团队）把所有的术语和项目相关的名词、缩写等都放在一个地方。
35. （带领团队）不要依赖于某个人的手动操作，而是要把这些操作都做成有相关权限的人士都能运行的脚本。这样就不会出现因为某人休假而项目被卡住的情况。
36. （带领团队）要让重用变得更容易。一个软件团队要创造一种环境，让软件的重用变得更容易。
37. （带领团队）在每一次迭代之后，都要总结经验，让下一次迭代的日程安排更可靠。
[ii] Jim Barksdale 是Netscape 公司的CEO, 他提出了Snake Rule，见到问题，就要解决问题，但是也不要沉溺于无法挽回的事情中。参见：MenkBlog 以及 Jim Barksdale Said It
附：
