总览
所有的弱点中，最大的弱点就是害怕暴露弱点。
注重实效的程序员对他自己的职业生涯负责，并且不害怕承认无知或错误。
负责
责任是你主动承担的东西。面对责任除了尽你所能之外，还需要分析风险是否已经超出了你的控制。对于不可能或风险太大的事，有权不为之负责。当需要承担责任时，你必须依照自己的道德标准和判断来做出决定。
控制
假如在团队开发中，出现了一个无法控制的事务，且没有完美的解决，该事件久了能引发更多不可预知且不可控的事件。不可控的事件的熵总会趋向于最大化，这就是即便有着详细的计划，技术高超的开发者，但是软件还会开发失败的原因。项目成员的心理对项目有很大的作用，如果这种不可控变多了，最终软件可能因此腐烂。
标准
人们总会以最低标准来要求自己，特别是在有参照物的时候，人会更倾向于拿自己和最低的那个参照物相比较。在软件开发中，如果有一点很低劣的代码，或者管理者的一个错误决策，都有可能引起一场雪崩反应。人们总会容易产生这样的想法：“相中中有那么烂的代码，我只要写那样的代码就可以了，没必要太严格的要求自己。”，至于说项目在这之前有多好，代码在这之前结构有多清晰，注释有多明确，谁会去关注呢？
成就
首先，你有对整个系统的设计，整体构思。但是你不需要把整个系统全部拿出来，把自己的要求和期望全部详细的讲出来。在现今的企业管理架构中，同时请求太多资源或者对团队成员提太多任务，可能会遇到拖延和茫然。并且开会研讨，讨论审批，会让事情变得复杂化。每个人都会护卫他们自己的资源，不要让他们觉得你是哪个掠夺者。
可以先设计一部分比较合理的东西，等开发完成之后，就拿出来给大家看，首先先享受部分成功的喜悦，然后引导式的提出更多的功能需求或更多的优化点，最后等其它项目成员来确定并承担下这些任务。就这样，逐渐的把它们引导向整个项目的图景。
对于人们来说，参与正在发生成功的事会更容易让他们接受。能够让他们瞥见未来，你就能把它们聚集在周围。
大局
大多数软件腐烂都是从一点点的微不足道的小事开始的，大多数的项目拖延都是一天一天发生的。系统一个特征一个特性的偏离其规范，一个又一个的补丁被打到某段代码上，知道最初的代码一点也没留下，并且项目的设计也已经变得杂乱无章。常常是小事的积累破坏了士气和团队。
留心大图景，要观察项目的全局设计，要观察周围的环境和发生的事，而不只是做你自己在做的事情。
质量
我们无法精确的去控制软件的质量。作为研发者我们必须在保证代码的整洁高效的前提下，去满足软件用户的需求。
不管是公共库还是应用软件，我们的作品始终是要给用户使用的。质量需求很重要，尽量给用户直接参与权衡质量需求的空间。你应该将系统的范围和质量作为系统需求的一部分，规定下来。
无视用户的需求，一味的给程序增加新特性，或是一次又一次的润饰代码，等等行为都不是有职业素养的做法。
我们决不能向用户或其它领导许诺一个不可能兑换的时间标度，到最后为了赶上项目的最后期限而削减基本的工程内容。
收手
如果不懂止步，所有的辛苦劳作都会被破坏。
不要因为过度修饰和过于求精而毁坏完好的程序。让你的代码凭自身的质量运行一段时间，他也许不完美，你不用因此而担心它，没有完美的代码。
知识
知识上的投资总能得到更好的回报，你的知识和经验是你最重要的职业财富。但是这些财富是时效资产，随着新技术，语言和环境的出现，你的知识会变得过时。随着你的知识价值降低，对你的公司和客户来说你的价值也在降低。
知识资产
软件工程师所知道的关于计算技术和他们所工作的领域的全部事实、以及他们所有的经验都可以被视作他们的知识资产（Knowledge Portfolios）。管理知识资产与管理金融资产非常相似。
- 严肃的投资者会将定期投资作为一种习惯。
- 多元化是长期成功的关键。
- 聪明的投资者在保守的投资和高风险、高回报的投资之间平衡他们的财产。
- 投资者设法低买高卖，以获取最大回报。
- 应周期性的重新评估和平衡你的财产。
要想在职业生涯中获得成功，你必须用同样的指导方针管理你的知识资产。最总要的是你需要定期为你的知识资产投资。
学习方法
这里给出一些学习技术的方法，以供参考。
- 每年至少学习一种新语言。
不同的语言以不同的方式解决相同的问题。通过学习若干种不同的方法，可以帮助你拓宽思维，并避免墨守成规。 - 每季度阅读一本技术书籍。
- 也要阅读一些非技术书籍。
记住计算机是由人来使用的，你所做的软件也是为了满足人的需求。不要忘记等式这边的人，这很重要。 - 上课。
- 参加本地用户组织。
- 实验不同的环境。
- 跟上潮流。
- 上网。
是否在某个项目中使用这些技术，或者是否把它们放入你的简历，这些都不重要。重要的是学习的过程将拓宽你的思维，使你向着新的可能性和新的做事方式拓展。
批判的思考
批判的思考你听到的和读到的，你要警惕你所得到的知识的准确性，保持自己的大脑不要被错误的言论或知识所误导。
交流
最重要的问题不是你有什么，还要看你怎样去包装它。就算你拥有最好的主意、最漂亮的代码、或是最注重实效的想法，如果没有有效的交流，最终也会毫无结果。
主旨
在交流之前，首先规划好你要交流的东西，写出一个大纲。以能够表达出自己想要说的内容为目标，不断的提炼他。如果有时间的话，应该先去准备好几种把你要说的内容讲清楚的策略。
听众
只有当你是在传达信息时，你才是交流。为此，你需要了解你的听众的需要、兴趣和能力。我们不想看到这种情况：一个研发人员发表长篇独白，讲解各种神秘的技术优点，把所有的听众都弄得目瞪口呆。在我17年8月去宁波某银行演示系统的时候就犯过这种错误，后来回顾总结的时候意识到这种行为不是交流，而是空谈。下面引入一首离合诗，或许能够帮助你进行交流：
What do you want them to learn? 你想让他们学到什么？
What their interest in what you have got say? 他们对你讲的什么感兴趣？
How sophisticated are they? 他们有多丰富的经验？
How much detail do they want? 他们想要多少细节？
Whom do you want to own the information? 你想让谁拥有这些信息？
How can you motivate them to listen to you? 你如何促使他们听你说话？
时机
说话的时机很重要，不要因为分不清事情的轻重缓急，弄错了说话的时机导致无法达到本来的目的。
风格
根据不同的听众调整你的交流风格，有些人喜欢正式的“事实”简报，有些人喜欢在进入正题之前首先高谈阔论一番。如果需要正式的文档的话，在注重事实的基础上，尽量让你的文档美观一些。如果可能的话，在文档制作早期就让你的用户参与到文档的制作当中。获取他们的反馈，汲取他们的智慧。对于风格而言，请谨记：你怎么说和你说什么同样重要。
做倾听者
如果你想让别人听你讲话，首先你要学会听别人讲话。在进行交流的过程中，要学会及时的回复他人。除非你生活在真空中，你才不需要交流，否则请好好锻炼一下交流的技巧。交流的越有效，你的影响力就越大。
引用
本文是对软件工程师为人哲学的一点总结，主要参考了以下资料：
- 《马维达. 程序员修炼之道[J]. 程序员, 2004(4):121-124.》
非原创声明
>本文并非我的原创文章，而是我读书笔记。文中的材料与数据大部分来自于其它资料，详细请查看本文的引用章节。
关于
本项目和文档中所用的内容仅供学习和研究之用，转载或引用时请指明出处。如果你对文档有疑问或问题，请在项目中给我留言或发email到
weiwei02@vip.qq.com 我的github:
https://github.com/weiwei02/ 我相信技术能够改变世界 。
