永远都是你的错
作为一名谦逊的程序员，最基本的要求就是要有意识：你写的代码在任何时候出了问题，那一定都是你的错。
在大多数项目中，你所调试的代码里常常混杂着这些东西：你和项目小组中的其他成员开发的应用代码，第三方的产品，以及平台环境。无论你的软件出现什么样的问题——甚至最开始出错的地方根本就不是你的代码——你也应该总是假定问题出在你的代码里，并根据这个假设采取行动。
说实在，程序员都有一种高傲的性格，一般都是不愿意承认问题出在自己那边。而且出错之后一定会背负领导或者其他各方的压力的。可是事实永远不会因为你的否认而改变，该背的锅还是得背的。
大道至简
代码不是什么好东西。代码会随着时间的推移慢慢腐烂。代码需要周期性的维护。并且里面还藏着bug。但是这些问题真正不在于代码，代码不是我们的敌人。你想看看真正的敌人吗？去照一照镜子吧。问题就在那里！
作为一个软件开发者，你就是自己最大的敌人。你越早认识到这点，你的境况就会越好。
在编码的过程中，你可以从很多维度评价你的代码：
- 代码的简洁度
- 功能的完整性
- 执行速度
- 编码所花费的时间
- 健壮性
- 灵活性
我们想要的是一个实用而明智的策略，以缩减一个程序员在想要了解程序的工作原理时所需阅读的代码量。
对于一个具体的需求，软件编程向来都是大道至简，然后依据测试的结果按需提升其他的维度。
避免写注释
你应该总是专注于编写代码，而忘了还有注释这种东西存在。
这里并不是让大家不要注释，否定注释。相反，我认为注释是很重要的东西，用很多注释装饰代码是件好事，但是在代码中加入大片大片的注释反而不是景上添花。
注释不是给编译器看的，注释是用来和其他人交流的，你所要做的是在代码核心处与实用方式上添加注释，其他地方你可以使用编程技巧使代码通俗易懂。
注释不是那么简单的，好的注释取决于你是否是一个好的作家，是否有良好的沟通能力。作为一个软件开发着，真的是不容易。
一些有趣的注释
学会读源代码
在沟通这个复杂的领域，写出能让人类领会并理解的连贯的段落比敲出几行不至于让解释器或编译器呕吐的软件代码要难的多。
这就是为什么——就软件开发而言——所有的文档大概就是很差劲的，而且，由于为人写作比为机器写作要困难的多，恐怕在可预见的将来，文档还会继续差劲下去。
对此，你基本上无能为力的。
不管文档上面怎么说，源代码才是最终的事实，是你所能找到的最好的，最确定的，最新的文档。
在此，并不想否定文档的作用，相反文档是很重要的，只是想要强调阅读源码的价值。但是，阅读源码是一项费力的活，耐不住寂寞文档就是很好的工具。
向橡皮鸭求助
遇到解决不了的困难时，恐怕你做的最多的就是去网上寻求帮助，应该没有人等待并祈祷着吧！
在寻求帮助的同时，你应该：
- 用足够多的细节来描述发生的状况，尽量让别人能了解到底发生了什么事情。
- 告诉他人你为什么需要知道答案，是闲来无事的好奇，还是在具体的项目中遇到了障碍。
- 说一说为了解决这个问题你都做过什么研究，以及你自己的发现。别人没有义务花费时间来帮助你，你应该有自己的分析。
- 适当的组织你的问题，酝酿一个合格的问题可能会帮你更快的找到答案。
- 如果解决了问题，尽量点赞和喝彩，积累的点赞可以帮助后来者快速注意到解决方法。
创新以人为本
上面的标题需要这样断句：创新，以人为本。这一小节讲的是执行力的问题。
一个好的创意值多少钱？可能它有点值钱，但是也值不了多少。创意本身不会毫无价值，但是很显然，单有创意只是空头支票。好的执行力才是好创意的倍增器。
在软件开发领域，执行意味着专注于构成你的应用程序的所有微小细节。如果你不是始终沉迷于你的应用程序的每个方面，不去持续优化和改进它的每一处细节，那么你就不是在执行。至少，不是在很好的执行。
你的团队执行得怎样，决定了他们会把你的创意从黄金变成废铁，还是从废铁变成黄金。
创意需要人去执行的，甚至整个团队去执行的，所以最后执行力还是取决于程序员本身，是以人为根本和基础的。