目标
从改变你看待代码以及编码的方式开始。你需要理解所编写的每行代码背后的业务成本；你需要从客户或者最终用户的角度来看待工作；你需要接受代码会比你在组织中存在的时间更长，所以要以其他开发者能够继承的方式来设计；最重要的，永远都不要害怕新的挑战，也不要害怕请求帮助，你无法独居一隅来提升工作效果，软件开发也是社会化的工作。
好的程序员
先做研究
或者称作“三思而后行”，或者称作“谷歌一下”。
无论你怎么称呼它，你可能遇到的大多数编程问题几乎在一定形式上都已经被解决了。传道书早就记录在案，阳光底下无新事。在GitHub上的库文件列表中，在因特网上的博客中，或者恰好与某个人经验交流中，好的程序员知道要在解决一个问题之前先做研究。
我曾经见过伟大的程序员急于给出解决方案，但是我曾经一起工作过的最糟糕的程序员，从来不咨询他人，从而导致做了大量的重复性工作或者恰好使用了错误方式来解决问题。于是很不幸的，他们最终为他们的错误付出代价。
读错误信息
这包括对堆栈追踪的符号解析。是的，令人厌恶而且不幸——但如果你不愿意这么做，怎么知道哪里出错了？我知道的最高效的程序员不害怕深入挖掘问题。最低效的程序员看到错误甚至都不愿读错误信息。（这听起来挺可笑的，但我遇到的频率会让你吃惊。）
更进一步说，伟大的程序员看到问题，会急迫的去解决它。对于他们来说，读错误信息仅仅是第一步；他们渴望深入问题并找出错误的根源。他们对推卸责任没有兴趣，他们对找到解决方案有兴趣。问题确实在他们这里止步。
积极推动测试活动 ，重视测试用例
只有测试才能保证软件可以正常工作，只有测试才能保证软件的质量。无论什么产品，都需要经过或多或少的测试。测试地充分的产品，你会发现其质量总是那么好，测试的不充的产品，质量总是那么次。在你开发软件的过程中，如果你说你的程序写地好，质量高，那么请你拿出实实在在的测试报告。在整个软件开发过程中，做为一个好的程序员，你应该积极地在各个环节推动项目组进行测试活动。不要以为技术需求阶段和设计阶段不需要测试，一样的，只要你要release什么，release的这个东西都需要进行测试。技术需求怎么做测试？用户案例就是测试案例。
要聪明但不要“小聪明”
不反对走捷径，但是一定要论证充分，否则，可能会产生很多潜在的bug。编码中走捷径也许能够提高程序的可读性以及效率，但是如果论证不充分，不能把所有的潜在问题考虑周全，很有可能犯了丢了西瓜拣了芝麻的错误。最好的论证方法是多和他人商量，请别人检查自己的工作，将问题提早暴露。所以，不要为了做成某件事却忽略过程的连带效应，也许有一天你会为你当初的“小聪明”买单。
寻找不同观点，接收新思维
程序员好像并不喜欢技术上有异见的人，他们特别喜欢争论各自的技术观点。但是，他们忽略了不同观点的价值。任何事情都有好有坏，我们应该学会在不同观点中学习和平衡。这样才会更多的了解编程和技术。要经常在做事之前问自己和别人，这么做对不对？做完事后问自己，还可不可以改进？努力去寻找别一个观点。程序员应该经常上网，经常和同事讨论不同的实现方法，不同的技术观点，这样才能取长补短。
学习历史，跟上时代
如果你是从十年前开始编程的，那么，今天的这门语言或是技术会有很多很多的改进和改善。你以前开发一个功能或函数，今天早已被集成到新语言中，而且做得比你的版本要好得多。以前你需要100行代码完成的事情，今天只需要1行代码。这样的事情在未来还会发生，所以，今天一定要学会如何跟上时代。但是，你也不要放弃历史，计算机世界的技术更新和技术淘汰非常猛的。只有通过历史，你才能明白历史上出现的问题，新技术出来的原因，这样才能够对今天的这些新的技术更了解，也才能明白明天的方向在哪里。学习历史和跟上时代都是相当重要的。使用新型的技术，停下来接受培训，可以让你工作得更快，更高效。而学习和总结历史，才会让你在纷乱的世界中找到方向。
善于沟通
说到底，编程也是一种交流的方式。能够简洁明了地表达出你的观点之于写代码就如其之于写诗一样重要——长久以来，我发现那些能够写出精炼的电子邮件、优雅的报告或者仅仅是高效的备忘录的人通常也会是更优秀的程序员。
这个发现对写程序和对英语一样使用。当然，把充斥着括号和只用一个字母命名的函数写在一行里面也是可以的，但是如果没有人能够理解你写的代码，又有什么意义呢？无论使用什么媒介，优秀的程序员会把时间花在如何将他们的观点更好地表达出来上面。
激情四射
我想这是最能够体现一个好的程序员的地方（并且，不仅在计算机行业，这点适用于任何行业）。
如果你真正关心你做的东西——不只是把它当做一个工作去应付，而是一个兴趣、一件对你有着莫大魅力的事情，那么在这个行业里，相较于其他人而言，你就拥有了一项巨大的优势。好的程序员会一直保持着写代码的状态，他们每天花在这个行业里的时间都不低于8个小时——包括工作和空余时间。在编写项目和授业解惑两者之间，他们不会偏向任何一方。他们不会只是为了搞清楚某个东西的工作原理而整天痴迷于新技术或新的编程语言。
当我观察一个周日正在做自己感兴趣的项目、在创造自己需要的工具、被新的、有趣的事物吸引的程序员的时候，我意识到我正在观察一个会令所有人都不由自主心生敬意的人。最后，伟大的程序员不会将他们的专业看做赚钱的工具，而是一种改变世界的手段。我想这就是早就一个伟大程序员的真正原因吧。编程，对于他们来说也就意味着创造世界。也只有这样的人，才值得我们由衷地敬佩和景仰。
坏的程序员
代码写完了，我完成了
如果编程是做爱的话，一定有很多没有被满足的电脑。你不能简单的进入，做到一半然后就睡觉了。很多程序员都没有搞明白“完成”是什么概念。请记住：完成意味着测试通过（不仅仅是单元测试），文档完整，提交，合并……
不加理解的拷贝代码
你经常会发现你需要的代码在一些别的程序里面有。整段的拷贝代码并且就这么使用它而不去烦恼于理解每一行代码是很诱人的。
有时候你拷贝的代码可能太大了以至于没有时间去完全理解它。如果你拷贝任何代码都像这样，就会有让你的程序变得脆弱易出bug等风险。
这样可能让工作完成，但是如果这段代码在某种情况下产生了一些意外的行为将会怎么样？如果使你的程序变慢或者有恶意行为将会怎么样？因此需要恰当的理解这些代码，或者需要绝对的确信你拷贝的代码的出处。
如果以后产生了bug，你会发现很难理解这些代码，因为你从来没有写过它。甚至于你会发现很难去找出bug并且修复它，特别是如果拷贝了很多代码在程序的不同地方。
所以当拷贝代码的时候要小心，即使很少的代码。确保你完全理解它了。如果你以前用过一段代码并且可以百分之百的保证它可以工作，那么它是安全可用的。但是如果不是的话，就要当心了。
每次都从头开始
这和我之前说完全相反，但是这确实是初学者容易犯的另外一个错误。
也许你认为每次都从头开始会很好，但是实际上它浪费了太多资源–时间，精力和思维，你可以更好的在其他方面使用它们。
如果你需要的东西已经存在了，那么使用它们。不要反复重复最基础的东西。
你可以使用这些时间让你的应用在其他方面更加优秀。
如果一个API、框架或者游戏引擎让你的任务更加轻松，你没有理由不适用它们。你的目标不是展示你有多么的优秀，也不是证明你可以独立完成任何任务。你的目标是保证你的应用完美工作，并且尽可能少花费一些资源去创造它们。
如果你这样做，你可以用更少的时间去完成同样地工作。时间就是金钱，即使是你为你自己工作，你也应该试着在同样的时间赚更多的钱。
忽略警告
这是一个早期我进行程序开发时犯的另一个错误。我不能告诉你当你的程序中出现几百个警号和一次都不出现有什么大的不同-最重要的是忽略掉它就出现新的问题。
警告通常是你做的东西可能不是每次都能正常工作的一个标志。有时，忽略这些警告会造成很大的安全问题。但是真正的问题通常是出现在程序出现几百个警告，或者程序不能正常工作时。
很难确定到底是什么原因造成了那个错误，你必须花更很多的时间来分析每一个警告来找出造成问题发生的根本原因。相反，你可以在警告发生的时候就处理掉它。
通常你仅仅需要使用正确的变量或者正确的函数来处理这些警告。不会花你几小时，只需要几分钟遇到它们就把它们处理掉。
要尽早的处理警告。干净的代码看起来舒服工作起来也会很高。记住- 对待警告和对待错误一样。
快速修复而不是永久性解决
是的，我对这样做感到愧疚。我不为此而自豪。但通常，我们仅仅是草草的修复一下，很少会去从根本上解决这个问题。
它能正常工作了，问题也处理掉了。但是如果你一不小心，问题又会以不同的方式重新出现。
无论你怎么修复一个问题，都应确保你不会把整个系统破坏掉。修复应该提升整个系统的运行状况，而不是让它更慢或更笨重。
同时，进行一个修复要能永久性的解决这个问题。要长期，不要短期。有时，由于懒惰和无知，我们通常喜欢快速的把问题解决掉，而不想在上面花太多时间。这就是为什么我们的写的代码能正常的工作，但是却不是在所有情况下都能工作。
如果你在工作的时候把它忽略掉，你会在后面花更多的时间。
了解上面这些错误能有助于你避免它们。如果你知道你所做的是错误的，一般来说你就不会去做。
为了把工作干好你应该热爱你所做的。如果因为某些原因你不喜欢编程了那么你几乎不会花额外的功夫来编写好的可维护的程序。
如果你打算写一手好程序那么你就应该 改变你对编程的看法。
你要把编程看成一门艺术而你自己则是一个艺术家。那么你就不会因为懒惰和不小心而犯错。
作家会把一篇未完成的文章发表么？画家会把未完成的画作拿来出售么？歌手会在他的歌中唱没有用的歌词么？
绝不会。
对编程来说也一样。任何情况下，都别编写未经测试的半吊子代码。在你的程序未写完前，不要发布它。别编写不会使用的无用代码。
这都是一些我们犯的一般性错误，因为我们喜欢在工作花更少的时间而去干其他事情。但这是不行的，迟早你都会为确保你的代码不出问题而负责。
越早的练习正确的编程方法，就对你的用户和自己越好。有时成为一个好的程序员意味着你不会犯糟糕程序员同样的错误。
羞于请求帮助
一般的程序员羞于或者不想让人知道自己不懂，所以他们装作什么都知道，但这样就有可能提交某种非常可怕的代码到库中。说“我不知道怎么做。”没什么错，强大的程序员知道这一点，所以当被问题难住的时候就会请求帮助。
相信自己的代码
在任何时候，一定要高度怀疑自己的代码，保持清晰的文字注释。很多时候，错误总是自己造成的。所以，当被反馈问题的时候，要学会review代码中所有的可疑点，用户不会无缘无故的投诉问题；千万别觉得某段代码很简单，可以略过。事实证明，很多疏忽大意都是在阴沟里翻的船，都是那些很低级的错误。
在查错的过程中，切忌过早下结论，切忌四处乱改， 停下来，想一想，会是哪儿的代码有重大嫌疑，然后查看一下代码，捋一捋程序的逻辑，调试并验证一下程序的逻辑和变量在运行时是否是正确的。很多时候，对于 那些难缠的问题，最后解决了总是因为我们开始认真回头审视所有的代码。只有对自己的代码保持着高度的怀疑，这样我们才会想着如何让其运行得更好更稳定，也会让我们在单元测试中下更多的功夫，这样才能更能在那忙碌的环境中节省时间。在集成测试中修改bug的成本要比在单元测试修改bug的成本大得多的多。程序员对自己的程序需要有忧患意识，这样才会越来越成熟，而自己的能力也会越来越强。
不知道如何让其他程序员更容易使用你的代码
在所有技术团队中，工作很重要的一部分就是人员的并行（human parallelism），也就是多个人能够同时对同一代码库工作的能力。但是对于团队来说，能够异步工作也很重要，当你不在的时候我可以修改你的代码，反之亦然。
一般的开发者并不这么认为，他们会开始对一项任务编写代码，认为他们会永远拥有这段代码。而强大的开发者会知道技术债务的说法，从而试图通过设计代码来对其限制，让它尽可能可维护和自解释。
编写可读的代码需要程序员改变他们的看法——你的代码要比你在组织中存在的时间长。
不能从最终用户的角度编码
有句话说得好：作为程序员，你的工作不是解决技术问题，你之所以解决技术问题，是为了解决业务问题。
一般的程序员只会陷在技术问题之中，而不知道最初是为什么要解决这个问题。更严重的是，一般程序员无法从头开始创建出具有业务价值的东西。当被要求基于简单的用户设计新特性的时候，他们会死板地、照着字面对故事或者说明书做出解释，这样交付的产品用户根本无法使用。因为他们不会考虑相关的用例；不会考虑最终用户的体验；并且在做面向用户的内容时，设计都会很笨重。这导致他们无法编写业务应用，只能做产品。
好的程序员会从最终用户的角度来看他们的代码。我怎样才能让它更轻松地解决用户的问题呢？故事的文字内容之外有哪些方面会让这个特性给用户带来更多收益呢？
等待、找借口以及抱怨
当需求不明确的时候，当环境不是很满意的时候，他们总是在等待别人的改善。出现问题的时候，总是在找借口，或是抱怨这也不好，那也不好，所以自己当然就没有做好。糟糕的程序员总是希望自己的所处的环境是最好的，有明确的需求，有非常不错的开发环境，有足够的时间，有不错的QA，还有很强的team leader，以及体贴自己的经理，有足够的培训，有良好的讨论，有别人强有力的支持……，这是一种“饭来张口，衣来伸手”的态度，这个世界本来就不完美，一个团队需要所有人去奋斗，况且，如果什么都变得完美了，那么，你的价值何在吗？
资料参考
- 五个方法成为更好的程序员
- 优秀程序员必备的23条好习惯
- 程序员经常犯错的7个坏习惯
- 十个让你变成糟糕的程序员的行为
- 两程序员不同境遇：少抱怨 多解决问题
