如何成为杰出的程序员或软件工程师？
怎样的程序员才算优秀的程序员，他应该具备有哪些素质。
按投票排序
我不能算是一个很优秀的程序员，但这个问题我已经反复思考了五年了。跟大家分享一下我的看法：首先， 我认为答案绝对不是 "只要写很多年代码就好了“。我面试过不少有10年经验，代码却写的很糟糕的程序员。经验很保贵， 但只靠经验是不够的。就像下棋一样，假如你用心研究，复习，不断挑战自己，也许可以成为一名大师。但不断用懒散的方式去玩棋，下20年也只是一个"臭棋篓子“。我觉得比较有用的进步方式：1. 学会看代码大多数程序员都只愿意用自己写的代码，但高手一般可以轻易调用别人写的代码。表面看上去是工作习惯不同， 但实际上是能力上的差别。看代码要比写代码难很多倍。我建议上班时多给队友们作code review，下班后试着阅读github上的开源代码。2. 复习程序员一般都很忙， 手上有永远也做不完的活儿。但在某些公司里， 你只是在反复做同样的事。偶尔放下手上的活儿，留下一部分时间来分析自己的弱点，更改坏习惯，看新书， 或学习新语言。3. 做个人项目工作中的编程一般只能让你熟悉一部分技术， 导致漏洞的形成。这就好像你长期一个人在自己后院练习投篮， 但第一次打比赛才（在惨败中）发些原来还需要传球， 防守， 强篮板这些概念。Facebook喜欢雇佣所谓的 “full stack programmer”，就是一个人从设计，到交互，到html， css，javascript， server，sql， 架构，和数据统计都能做。成为full stack programmer最好的方式就是不断做个人项目。4. 问答网站问问题和回答问题都是很好的学习方式。 有的时候写出一个好问题， 比写出解答次问题所需要的代码还难。写问题可以帮你整理自己的思维逻辑。你可以试着每周在上问一个好问题或写一个好答案。5. 加入一个好团队最好的进步方式就是跟比自己强的人一起做事。高手都愿意聚在一起，所以很多会选择去优秀的早期创业公司。我在硅谷和创新工场创业时遇到了很多神人， 跟他们学了不少东西。
原作者： , 基础架构组工程经理日作为一名工程经理，我经常被同事和面试人问“作为一个Coursera工程师，我的职业生涯发展是什么？”尽管有些人更希望成长为经理，但我发现还有很多人对如何成长为独立贡献者（ individual contributor）更有兴趣。所有在Coursera工程师共享同样的名称：“软件工程师”。你可能会认为这会导致模糊的职业发展，但我们相比严格的等级，更喜欢这种模式，理由如下。我们是一个小的，紧凑的工程组织下的创业公司，我们专注于一起工作，共同实现我们的使命：为全世界提供最好的教育而奋斗。每个人在没有被人为组织结构，职称和角色所羁绊下去发挥其最大的潜能。我们的文化体现着谦逊。杰出的工程师认可是被公认的贡献，领导力和态度，而不是他们的头衔。每个人都是领导者。我们的文化是非常开放的，包容的;一些最好的想法，往往来自刚毕业大学生或实习生。我们渴望帮助每个人在这里成长为技术带头人。作为技术人员，我们正不断努力改善我们的技能，帮助我们的工程师不断提高。我们希望在这里的工作，是我们自我变革的体验，并以同样的方式去改造公司的轨迹。为了指导我们的工程团队，我们列出由一些杰出高产的工程师都体现的品质列表。这些都是我们在Coursera，以及其他硅谷高科技公司同行，如LinkedIn，谷歌和Facebook所钦佩的优秀素质。我们分享这个列表，并希望激发其他工程团队去思考他们看重的素质，以及如何建立，培养和奖励优秀人才的企业文化。如何成为一个伟大工程师结果驱动伟大工程师产生了伟大成果。 Coursera重视工程师从开始设计，实施到交付一系列环节。这里的原因：对于任何重大项目，往往是在细节中出问题。比如产品推出，运营服务，产品功能。在交付和运营的服务或产品上体现主人翁意识，这是我们的核心价值观。结果会直接给业务增值。我们认为一个员工的贡献累计来自于如何衡量增加的价值。影响力可以来自于很多维度，包括增值，活跃度，收入，工程效率，网站稳定，可扩展性等等。显著影响力在交付MVP（最小核心价值产品）很少能够实现。在我们搭建的产品和需求中不断的迭代才能最大化我们的价值。我们的指导方针是“”的原则，我们赞赏能够平衡执行速度，编写可扩展组件和代码质量。我们也看重“10倍工程师”，即不仅能快速提供高质量的结果，同时也激励和指导别人更聪明地更快的工作。领导力领导者不一定是一个管理者。技术领导是说的你的工作方式。你把你的项目，团队，整个技术组服务好。最好的工程师显示至少其中的一些特质：项目领导：伟大的工程师们可以从不同的项目中担任技术负责人的角色，项目的范围从小到大，影响力从低到高。他们能驾驭好点子，阐明设计，排除阻碍，不断改进。他们跟产品组合作确立正确的产品上线顺序，他们知道在质量，完成度和速度如何权衡考虑。有时他们通过数据驱动决策保证项目完成。找出差距：伟大的工程师们能够广泛地思考面临的差距和问题。更重要的是，他们是第一次去发现我们从来不知道我们有的问题。他们更看重解决问题而不是抱怨 - 事实上，他们渴望保持手勤，用创造力和真正的热情应对面前的挑战。“向上看齐”：伟大的工程师们往往围绕比他们更好的工程师。他们是以身作则提高生产力，领导和激励他人。他们通过代码和设计评审来作为导师帮助大家。爱学习：伟大的工程师为了不断提高技能，他们热情地阅读技术文档，研究论文，和博客。他们喜欢上课，吸收别人的经验。组织存在感：伟大的工程师在整个组织中传承知识和经验。他们通过技术讲座，读书分享，Hack大赛去分享他们的工作。一个伟大的工程师可以在外部发表博客文章，会议演讲，或发表研究论文。影响力：伟大的工程师影响其他工程师采用新技术，架构，流程和标准。这可以通过他们能影响到的工作空间距离或者代码审核队列的大小来衡量。态度：像所有Coursera的员工，优秀工程师们关心队友和保持谦卑。他们认识到，每一个错误其实是有机会让他们做的更好。技术卓越伟大的工程师在技术上的优秀体现在很多方面：他们可以是厉害的产品黑客，算法高手，注重细节的基础架构工程师，或以上所有。我们重视在设计解决方案时深入思考，考虑复杂的产品和基础设施问题的工程师。伟大的工程师设计是强大的，直观的，可扩展的，灵活的，可维护，可操作性，可扩展性和高效的。他们努力质量和执行速度之间实现平衡。权衡除了业务目标的贡献，伟大的工程师通过提高工程团队的工作效率，构建可重用的组件，提供工具，使代码库更好管理这些都能整体性提升工程组织。这意味着构建抽象的服务或组件，使它们成为多个产品的需求或提高开发人员的生产力。这也意味着主动去构建工具，提取函数库，修复破碎的窗户，编写工程文档，或测试用例。这不是一个清单！伟大的工程师不一定擅长在上面列出的所有领域，但必须擅长一些。他们可能是非常全面的，或者在少数项目上极其突出。像下面的游戏人物，你不大可能就像塞西尔（左）全面高分;但你可能更像哥拉斯（右）更加均衡。在Coursera我们怎么使用这个列表？我们在内部表扬一些体现了这个标准中可以表率的工程师。独立贡献者使用这个文件来追踪他们事业上的进步，我们都添加注释，故事和例子，以便其他人可以了解谁做了了不起的事情。在Coursera工程经理使用此文档对团队成员在1：1会议，和绩效考核中去反馈评价。任何人当他们看到其他人做很棒的事情都可以直接说出来。这可以在发生在 1:1 (两个人的会议)，全组大会，技术部大会，通过Slack频道（企业通讯工具），或通过电子邮件。最后的话在Coursera，我们为全世界提供最棒的教育资源。我们想把高质量的教育，不再只提供给精英，而是公平的环境。同样，在我们的工程组，我们想创造一个让每一个工程师能够实现伟大的环境。我们提倡透明制度和包容性，并提供质量为导向的这份列表，来帮助工程师继续改进。
以下内容摘自博文“编程巨星的唯一秘诀”，中文翻译在此：只有一条真理决定了一个软件程序员的成功还是失败。由于坚持这个真理，一个资深的程序员能在一天的时间里学会一门新的编程语言，而由于不坚持这条真理，一个初级的程序员用十年时间也只能挣到一份糊口的钱、永远是来实现别人的设计、永远不够优秀而得不到晋升的机会。这条真理让你看清了差的程序员和好的程序员的不同之处，好的程序员和伟大的程序员的不同之处，伟大的程序员和能通过自己的技术创造出一个亿万美元价值的程序帝国的超级程序员的不同之处。不是什么复杂的道理，不是什么难懂的理论。不是具有什么天赋或“编程超能力“才能做到的事情。最终成为的是一个优秀的程序员还是一个很烂的程序员，这跟你的出身一点关系都没有。而真正的原因只有一个，唯一的一个：对所做的事情的理解越深，你就会做的越好。超级程序员跟那些平庸的、一般的程序员比起来，对自己要做的事情的理解要深的多的多。这就是原因。
参照 Quora 的答案：优秀的与伟大的软件工程师（似乎我们都说成程序员）的区别是什么？ 第一名 2500+ 票：- 能够平衡实用与完美。 Able to balance pragmatism and perfectionism- 不怕调试和修复BUG。 Not averse to debugging and bugfixing- 健康的怀疑态度。 Healthy skepticism—— , former CTO & Co-founder, Yelp第二名 1500+ 票：1. 这不关于他们写了的代码，而关于他们没必要写的代码；2. 这不关于他们代码库增长有多快（依据于代码的行数或复杂度），而关于他们怎么将代码库缩小同时不丢失功能或特性；3. 如果你尝试去跟他们争辩“什么编程语言才是最好的”， 他们是微笑、又或者对这个厌倦，然后转移话题么？或者，他们布教么？如果他们布教，那他们不是一个伟大的工程师；4. 这并不关于那些代码或编程语言，也不关于他们的痴迷、技艺、天赋、或其它虚假的魔法形容词。最简单地，他们是否在代码之上的层面了解软件？他们是否在架构层面明白软件？还是说他们只能去想代码的行数？他们可以在抽象的数学问题和软件之间切换么？他们可以跟利益相关者一起工作并理解那些人对系统的需求，或者他们会不会开发一个他们想要开发的系统——他们认为你真的想要这个？一个人可以成为一个伟大的骇客或编码者或程序员，但那与一个伟大的软件工程师不一样。我并没有使用一个价值量表，一个伟大的程序员也是一个伟大的程序员……但是你不能要求一个焊接工去建一座桥。5. 他们能否“发现缺陷盲点”，当房间里其它所有人都正迷恋于一些解决方案或新玩意时？此外，还能解释这些基础的缺陷点、让房间里**所有的人**都对这个缺陷点有清晰的认识？6. 他们能否倾听？如果他们不能，那他们不是一位伟大的软件工程师。原第二名 340 票：- 有天分 Talent- 自律 Discipline- 有经验 Experience- 有商业意识 Business-awareness- 有社交意识（合作意识） Social-awareness—— , Founder at RethinkDB# 更新于原来第二名被排到好后面去了，虽然票数从193票上升到340票
我来回答后一个问题，关于薪水的。----------------------------------------------------------------如果你是个优秀程序员，挑大梁的，实际上，你一个人给足够的时间，你就可以完成完整的一个项目。从设计到实现到测试到发行。书上说软件工程，说teamwork没错，但是优秀的程序员是从头到脚啥都能干，都能干好的。能挑大梁，老板高薪保你一个人的忠诚度就可以保证技术团队的稳定，其他人都是外围，replaceable，所以他们只能拿零头，你服不？从一个方面，这样的人离职带走的就不是一个模块，而可能是整个产品线。尤其是中小企业，伤不起啊，所以高薪是必然的。股权也是可以考虑的。拿得比所有经理多，你服不？就算是大点的项目，优秀的程序员做上层的设计，功力稍微有一点不同，就可以造成整个项目开销上巨大的区别。高薪是值得的。在架构设计上节约钱，老板除非脑子进水。来了牛人，直接节省开支100万，发50万奖金，你服不？还有的程序员本身是博士出生，可以搞研究，兼具科研能力，直接搞定公司的核心技术壁垒。他们高薪你服不？要不就是跨专业的，跨度大，达到很奇葩以至于公司做某个项目时候非他不可，高薪，你服不？...-------------------------------------------------------------------所以你也就看到什么叫优秀了。标准很简单，随便你到哪里，离了你不行。不可替代
37条来啦——条条通往自由之路成为杰出程序员，意味着你将获得诸多自由：财务自由，时间自由，心灵自由。谁不向往自由——然而，自由的一面是必要的约束，比如下面你会读到的软件工程师能力自我评价表（37条）。软件工程的奠基人之一瓦茨.汉弗雷总结说，软件领域可以分为两个方面：一方面是技艺创新的大爆发；而另一方面是坚持不懈的工程工作，包括软件的改善、维护和测试等，这一方面占了90%-95%的比例。（详见第三章）绝大部分软件工程师都不是技术天才，但却都可以通过坚持必要的约束（训练），成为杰出的程序员（软件工程师）。最近我们出版的这本书得到诸多好评，比如：请看： （多看版已上线：）书中第三章的主题是“软件工程师的成长” ，作者邹欣老师结合中国软件行业的特点，归纳出在中国IT行业“好工程师”的要素，并做成一个自我评价清单：（37条）1.保持高标准，不要受制于破窗理论(broken windows theory)。当你看到不靠谱的设计、糟糕的代码、过时的文档和测试用例的时候，不要想“既然别人的代码已经这样了，我的代码也可以随便一点啦。”2. 主动解决问题。当看到不靠谱的设计，糟糕的代码的时候，不要想“可能别人会来管这个事情” ，或者“我下个月发一个邮件让大家讨论一下”。要主动地把问题给解决了。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. （带领团队）在每一次迭代之后，都要总结经验，让下一次迭代的日程安排更可靠。 参见： Jim Barksdale 是Netscape 公司的CEO, 他提出了Snake Rule，见到问题，就要解决问题，但是也不要沉溺于无法挽回的事情中。参见： 以及 附：
我觉得成为一个杰出的程序员最重要的是"创造性“，比如：他不时有好、新颖的想法出现，并且具备能把这些想法变成现实的能力；对于一般人习以为常的例行工作，他能想出更好更有效的方法方式去完成，他弄出来后，别人才感叹：这么简单，我怎么想不到呢？……至于代码写得漂亮，学习能力强，掌握多种编程语言，对技术理解透彻等等，那也是他的特征，但并不足以让他成为”杰出“的程序员。另外，”杰出“不”杰出“，是看他己经做出的事，不是看他能做出的事。
最近看了一些关于程序员的职业发展思考的文章，然后听了场公司一个写了10年代码的程序员的培训，工作后也和蛮多的程序员合作过,程序员的自我修养如何修炼，才能有比较好的职业发展路径，站在PM的角度谈下自己的想法仅供参考： 1.事情做得专业的前提是能关注到细节
我觉得细心谨慎是程序员最基本的修养和素质，逻辑能力啥的倒是更为上一层的事情。整天想好的算法和架构是没有用的，你知道当你跟产品经理说解了半天的bug是因为少了个分号的时候，产品经理心中鄙视的是多么的波涛汹涌么。
如果连这些代码基本的细节都不能注意的话，谈何其他呢2.尊敬每一个人就像尊敬代码一样
很多程序员是傲娇的，觉得产品就是自己做出来的，其他的人都是辅助的。所以很多程序员心里是看不上产品，测试的，也就造成很多沟通障碍。
首先上面这种人一定一辈子只能写代码，哪怕技术再牛。
我不太认同写代码只能写到30岁，但是程序员30岁之后，要想有更大的发展，那么做团队管理，要么做技术咨询，才能让自己的能力和积累的经验扩大化，那么这个时候，卓越的沟通能力往往成为关键。 3.用经验堆砌出你的产品技术全局观
这个就涉及到架构方面，产品经理提出需求，不仅仅想听到的是这个需求可以做还是不可以做这么简单，而是如果可以做，那么开发成本是怎样的，会对目前的系统产品模块造成哪些影响，有哪些的risk，如果不可以做，有没有好的替代方案或者简化方案。
如果在需求评估的时候，PM可以得到这些答案，一定会跪舔你的
当然，另一方面，如果在前期评估中，这些都没有想到的话，后期造成的种种后果也是需要程序员自己承担的。 4.做好情绪管理
理论上，程序员都是冷静的。但是现实中，情绪冲动的也是蛮多的，我不知道这样的性格会对写代码有何影响，但是因为情绪影响了判断就不好了，例如因为需求反复修改就索性说这个代码实现不了这种事情，终究会对自己的信誉造成很大影响的。这种事情我经常遇到。。。 5.技术要做到精益求精
编程语言那么多，多语言的程序员虽然抢手，但是如果是半瓶水的水平，估计也是没人愿意要的。
现在程序员非常多，是因为这个行业入门的门槛非常低，也就造成行业的水平参差不齐。做一个网站很难么，找个现成的框架，懂点数据库，建个数据表，前端再找个现成的模板，修修改改一个网站就出来了。
但是满足这样就完了？那么水平可能永远就是这样了，其实这其中每一个点都是可以研究的很深的，比如网站的大数据存储，如何提供程序并行运行的效率，，未来计算机行业的技术分工会越来越细，任何一个方面的专家都是相当有用的 6、职业规划，其实你没的选
听一个前辈讲，自己也对职业也很迷茫过，后来索性去创业了，但是失败的一塌糊涂，最后才明白，自己最会的还是写代码，最懂的还是Java，有时候其实你没的选 7.Stay hungry ，Stay Foolish
技术是永无止境的，好的程序员必须保持对于新的技术敏感度，保持学习的热情
同时看书学习可以更多的得到思维模式，可以在最快的时间发现问题的所在
如果没有好的思维模式，很多程序员遇到需求了，先百度，看看有没有相似的代码，遇到bug再去百度下，看看别人是怎么解的，这种永远只是码农而已
听说一本好的程序书籍至少要读12遍才能理解。。。
想成为一个优秀的软件开发人员,在今天,你该怎样发展你的职业生涯?这个是我总结的优秀程序员必备十大习惯。按照这些技巧和规则,你可以改善你的现状,由一个普通的程序员,成为一名优秀的程序员。学会学习就算是你有了10年以上的程序员经历,你也得要不断地学习,因为你在计算机这个充满一创造力的领域,每天都会有很多很多的新事物出现。你需要跟上时代的步伐。你需要去了解新的程序语言,以及了解正在发展中的程序语言,以及一些编程框架。还需要去阅读一些业内的新闻,并到一些热门的社区去参与在线的讨论,这样你才能明白和了解整个软件开发的趋势。掌握多种语言程序语言总是有其最适合的领域。当你面对需要解决的问题时,你需要找到一个最适合的语言来解决这些问题。比如,如果你需要性能,可能C/C++是首选,如果你需要跨平台,可能Java是首选,如果你要写一个Web上的开发程序,那么PHP,ASP,Ajax,JSP可能会是你的选择,如果你要处理一些文本并和别的应用交互,可能Perl, Python会是最好的。所以,花一些时间去探索一下其它你并熟悉的程序语言,能让你的眼界变宽,因为你被武装得更好,你思考问题也就更为全面,这对于自己和项目都会有好的帮助。理性面对不同的操作系统或技术程序员们总是有自己心目中无可比拟的技术和操作系统。只有一部分优秀的程序员明白不同操作系统的优势和长处和短处,这样,在系统选型的时候,才能做到真正的客观和公正,而不会让情绪影响到自己。同样,语言也是一样,有太多的程序员总是喜欢纠缠于语言的对比,如:Java和Perl。哪个刚刚出道的程序员没有争论去类似的话题呢?比如VC++和Delphi等等。争论这些东西只能表明自己的肤浅和浮燥。优秀的程序并不会执着于这些,而是能够理性的分析和理心地面对,从而才能客观地做出正确的选择。别把自己框在单一的开发环境中再一次,正如上面所述,每个程序员都有自己忠爱的工具和技术,有的喜欢使用像VC++一样的图形界面的调试器,而我更喜欢GDB命令行方面的调式器。等等等等。程序员在使用什么样的工具上的争论还少吗?到处都是啊。使用什么样的工具本来无所谓,只要你能更好更快地达到你的目的。但是有一点是优秀程序员都应该了解的——那就是应该去尝试一下别的工作环境。没有比较,你永远不知道谁好谁不好,你也永远不知道你所不知道的。使用版本管理工具管理你的代码千万不要告诉我你不知道源码的版本管理,如果你的团队开发的源代码并没有版本管理系统,那么我要告诉你,你的软件开发还处于石器时代。赶快使用一个版式本管理工具吧。使用什么样的版本管理工具依赖于你的团队的大小和地理分布,你也许正在使用最有效率或最没有效率的工具来管理你的源代码。但一个优秀的程序员总是会使用一款源码版本管理工具来管理自己的代码。做一个优秀的团队成员除非你喜欢独奏,除非你是孤胆英雄。但我想告诉你,今天,可能没有一个成熟的软件是你一个人能做的到的,你可能是你团队中最牛的大拿,但这并不意味着你就是好的团队成员。你的能力只有放到一个团队中才能施展开来。你在和你的团队成员交流中有礼貌吗?你是否经常和他们沟通,并且大家都喜欢和你在一起讨论问题?想一想一个足球队吧,你是这个队中好的成员吗?当别人看到你在场上的跑动时,当别人看到你的传球和接球和抢断时,你的团员成员能因为你的动作受到鼓舞吗?把你的工作变成文档这一条目当然包括了在代码中写注释,但那还仅仅不够,你还需要做得更多。有良好的注释风格的代码是一个文档的基础,他能够让你和你的团队容易的明白你的意图和想法。写下文档,并不仅仅是怕我们忘了当时的想法,而且还是一种团队的离线交流的方法,更是一种知识传递的方法。记录下你所知道的一切会是一个好的习惯。因为,我相信你不希望别人总是在你最忙的时候来打断你问问题,或是你在休假的时候接到公司的电话来询问你问题。而你自己如果老是守着自己的东西,其结果只可能是让你自己长时间地深陷在这块东西内,而你就更本不可以去做更多的事情。包括向上的晋升。你可能以为“教会徒弟能饿死师父”,但我告诉你,你的保守会让你失去更多更好的东西,请你相信我,我绝不是在这里耸人听闻。注意备份和安全可能你觉得这是一个“废话”,你已明白了备份的重要性。但是,我还是要在这里提出,丢失东西是我们人生中的一部份,你总是会丢东西,这点你永远无法避免。比如:你的笔记本电脑被人偷了,你的硬盘损坏了,你的电脑中病毒了,你的系统被人入侵了,甚至整个大楼被烧了,等等,等等。所以,做好备份工作是非常非常重要的事情,硬盘是不可信的,所以定期的刻录光盘或是磁带可能会是一个好的方法,网络也是不可信的,所以小心病毒和黑客,不但使用软件方面的安全策略,你更需要一个健全的管理制度。此外,尽量的让你的数据放在不同的地方,并做好定期(每日,每周,每月)的备份策略。设计要足够灵活 可能你的需求只会要求你实现一个死的东西,但是,你作为一个优秀的程序,你应该随时在思考这个死的东西是否可以有灵活的一面,比如把一些参数变成可以配置的,把一些公用的东西形成你的函数库以便以后重用,是否提供插件方面的功能?你的模块是否要以像积木一样随意组合?如果要有修改的话,你的设计是否能够马上应付?当然,灵活的设计可能并不是要你去重新发明轮子,你应该尽可能是使用标准化的东西。所谓灵话的设计就是要让让考虑更多需求之外的东西,把需求中这一类的问题都考虑到,而不是只处理需求中所说的那一特定的东西。比如说,需要需要的屏幕分辨率是800×600,那么你的设计能否灵活于其他的分辨率?程序设计总是需要我们去处理不同的环境,以及未来的趋势。我们需要用动态的眼光去思考问题,而不是刻舟求剑。也许有一天,你今天写的程序就要移植到别的环境中去,那个时候你就能真正明白什么是灵活的设计了。不要搬起石头砸自己的脚程序员总是有一种不好的习惯,那就是总是想赶快地完成自己手上的工作。但情况却往往事已愿违。越是想做得快,就越是容易出问题,越是想做得快,就越是容易遗漏问题,最终,程序改过来改过去,按下葫芦起了瓢,最后花费的时间和精力反而更多。欲速而不达。优秀程序员的习惯是前面多花一些时间多作一些调查,试验一下不同的解决方案,如果时间允许,一个好的习惯是,每4个小时的编程,需要一个小时的休息,然后又是4个小时的编码。当然,这因人而异,但其目的就是让你时常回头看看,让你想一想这样三个问题:1.是否这么做是对的?2.是否这么做考虑到了所有的情况?3.是否有更好的方法?想好了再说,时常回头看看走过的路,时常总结一下过去事,会对你有很大的帮助。
不请自答。如有谬误，欢迎指正 :)首先回答你的“为什么牛人会比新手薪酬高那么多？” 这里我们排除其他因素，只提我认为最关键的几点。1. 全局观2. 技术强3. 始终在进步首先说全局观。曾经听过一句话（有点记不清了，但大概是这个意思）：“如果你是一个普通职员，你需要计划到一天后。如果你是一个领队，你需要计划到一周后。如果你是一个主管，你需要计划到一个月后，如果你是老板，你需要计划到1年后”。这里就是全局观。你的职位越高，你所要预见到的未来，以及预计到的风险就必须更多，否则一群人跟着你去跳楼。所以回归到你的问题。作为大牛，他们看得东西远比新人要多的多。新人拿到一个任务，首先在想去google怎么搜，搜什么。大牛拿到一个项目，需要想“这个项目可不可以做，用什么语言来做，代码结构怎么设置，数据库怎么设计，安全性怎么解决，时间线怎么布置”等等等等。让你做一个页面当然不难，但是让你把一个网站的全部页面想好，函数接口都架构出来，你就发现这是新人绝对做不来的。《人月神话》这本书中有一个很好的例子，做项目就好像做一台手术。大牛就是那个主刀医师。所有人都是帮手并且来服务主刀医师的。如果是新人，面对着内脏甚至血管，他知道这一刀下去会有什么结果吗？显然不是。接着是技术强。解决一个问题可以有很多种方法。但是时间往往有限，假设一个新人可以很牛的在全局观中做的完美，那么接下来在实施过程中的各个技术难点，他有足够的时间和精力来一个一个去google吗？如何做到DB查找耗时极小，如果高效debug，如何巧妙的integrate各种莫名其妙的客户需求。。。所以在有限的时间里面，新人很难完完整整的把问题解决。而且更重要的是，全局观必须时时放在心上。你的每一个决定都有可能影响到项目的整洁度。IT项目往往伴随着超大的数据量。上百万级别的数据量，“不是你想改，说改就能改”。那么技术上的选择从一开始就决定了这个项目到最后是“没人看得懂”，还是“多少还能做做”。我知道的有些外国的IT项目，表面上看运行的很好，但其实后台也是一塌糊涂，连改都改不动。也许有人会问，为什么没法改？IT项目往往都是24小时不间断运行。所以你的每一个改动，都必须在客户可能没有察觉的前提下进行，而且最重要的是，改动之后的内容还必须支持之前的内容。比如，我为了客户安全考虑，把现在开始所有的注册客户密码全都加密存入数据库。但是这样一来之前注册的客户就全都不能登录了，因为数据库包含着两种不同的数据方式，一种是加密的，一种是不加密的。这不是在花样作死么。。。所以回到技术强，大牛肯定是要通盘考虑兼容性，然后做出改动，并且为将来做好准备的。最后，始终在进步。大牛是一种积累。也许你现在只能规划到“一天”这么远，但是日积月累，你自然就可以规划到“一年”这么远。就这份积累出来的经验，而且是超越技术的这种存在，大牛也是值得高薪的。他们就是知道的多，而且他们正在学习更多。而且作为管理层面上来说，我得到这个大牛，不光可以帮我把项目做出来，而且我将来的维护也可以比较低耗，而且他一个人可以在短时间内解决那么多问题，我自然要给他高薪。只要想想上面提到的“手术”那个例子，自然就明白为什么会有“A 50K programmer is better than 5 10K programmers.”这句话了。至于如何成为一个杰出的程序员或者软件工程师，其实我也不是很有信心可以回答这个问题。反正就是努力吧，还有一些思维的深度。请参考我的另一篇回答吧 :)谢谢，见笑了 :)
已有帐号？
无法登录？
社交帐号登录