第一版
务实（Pragmatic）这个词来自拉丁语 pragmaticus ------ "精通业务"，该词又来源于希腊语 πραγματικός ，意思是 "适合使用"。
"务实" 一词源远流长。
编程是一门技艺。简单地说，就是让计算机做你想让它做的事情（或是你的用户想让它做的事情）。作为一名程序员，你既在倾听，又在献策；既是传译，又行独裁；你试图捕捉难以捉摸的需求，并找到一种表达它们的方式，以便仅靠一台机器就可以从容应付。你试着把工作记录成文档，以便他人理解；你试着将工作工程化，这样别人就能在骑上有所建树；更重要的是，你试图在项目时钟的滴答声中完成所有这些工作。你每天都在创造小小的奇迹。
编程是一门技艺。同时它也需要和别人沟通。程序员可以和人很好地沟通，如果不能，可能就不会有人知道他，因为他是靠作品交流的。
这就让务实主义有了用武之地。你不应该拘泥于任何特定的技术，而应该拥有足够广泛的背景和经验基础，以便在特定的情况下选择合适的解决方案。你的背景来自对计算机科学基本原理的理解，而你的经验来自广泛的实际项目。理论结合实践会让你变得强大。
实践是检验真理的唯一标准。不必拘泥于特定技术，要有足够广泛的背景和经验基础，以便在特定的情况下选择合适的解决方案。背景来自于对计算机科学基本原理的理解，而经验来自广泛的实际项目。
调整方法去适应当前的情况和环境。对所有影响项目因素的相对重要性进行判断，并通过经验找到适当的解决方案。随着工作的进展，你要不断地这样做。
根据具体情况变通，依据经验和已有知识进行判断。
作为务实的程序员，会共有许多以下特征：
早期的采纳者/快速的适配者
你对技术和技巧有一种直觉，喜欢尝试。当接触新东西时，你可以很快地掌握它们，并把它们与其他的知识结合起来。你的信心来自经验。
好奇
你倾向于问问题。这真不错------你怎么做到的？你对那个库有意见吗？总在听人说起的量子计算到底是什么？符号链接是怎么实现的？你热衷于收集各种细微的事实，坚信它们会影响自己多年后的决策。
批判性的思考者
你在没有得到证实前很少接受既定的现实。当同事们说 "因为就该这么做"，或者供应商承诺会解决所有问题时，你会闻到挑战的味道。
现实主义
你试图理解所面临的每个问题的本质。这种现实主义让你对事情有多困难、需要用多长时间有一个很好的感知。一个过程应该很难，或是需要点时间才能完成，对这些的深刻理解，给了你坚持下去的毅力。
多面手
你努力熟悉各种技术和环境，并努力跟上新的进展。虽然目前的工作可能要求你在某个专门领域成为行家，但你总是能够进入新的领域，迎接新的挑战。
我们把最基本的特征留到最后。所有务实的程序员都有这个特征。它足够基本，完全可以作为提示来加以声明。
提示 1 关注你的技艺
我们觉得，如果你不关心怎么把软件开发好，那么软件开发领域就再也没什么好谈的事情了。
提示 2 思考！思考你的工作
为了成为一名务实的程序员，我们要求你在做事的时候，思考一下自己正在做什么。这不是对当前实践做的一次性审计
而是对每天里每一个项目所做的每一个决定进行的批判性评估。不要用自动辅助驾驶系统偷懒，而是要不断地思考，即时地批判自己的工作。 IBM 公司的座右铭 "思考！"，实属每个务实程序员的真言。
关注怎么把软件开发好最重要；
思考工作的意义；
多面手
现实主义
批判的思考者
好奇
早期的采纳者/快速的适配者
如果你觉得这听起来很困难，那么你就表现出了现实主义的特征。这会占用你一些宝贵的时间
可能是已经处于巨大压力之下的时间。当然会有回报， 你能更积极地投入喜欢的工作，对越来越多的学科有掌控感，对不断进步产生愉悦感 。从长期来看，时间投资将得到回报，因为你和你的团队将变得更高效，能编写出更容易维护的代码，并且在会议上花的时间更少。
处于巨大压力之下，让自己保持愉悦感。
务实的个体，大型的团队
有些人认为在大型团队或复杂的项目中没有个性的空间。"软件是一门工程学科，"他们说，"如果团队成员个体自行其是，软件就会崩溃。"
大型团队中不容许个体特征呈现。
我们强烈反对这种看法。
诚然，软件构造有工程的成分。然而，这并不妨碍个体的技艺。想想中世纪在欧洲建造的大教堂，每一座都需要数千人年的努力，时间跨度长达几十年。从中吸取的经验教训被传递给下一代的建造者，最终一代代累积的造诣推动了结构工程的发展。而木匠、石匠、雕刻师和玻璃工人都是手工艺人
通过吃透工程要求，其创造所体现出的整体水准，已远超建筑中纯机械的部分。正是他们对个人贡献的信念支撑着这些项目：我们，采集的只是石头，却必须始终展望着未来的大教堂。
在一个项目的整体结构中，总有个性和技艺的空间。考虑到软件工程的当前状态，这一点尤为正确。今天的土木工程师，很难接受中世纪大教堂建造者使用的技术
百年后我们的工程看上去也一样古老，而我们的技艺仍将受到尊重。
1 我的源码让猫吃了
注重实效的程序员的特征是什么？我们觉得是他们处理问题、寻求解决方案时的态度、风格、哲学。他们能够直接跃出直接的问题去思考，总是设法把问题放在更大的语境中，总是设法注意更大的图景。毕竟，没有这样的更大的语境，你有怎能注重实效？你又怎能做出明智的妥协和有见识的决策？
他们成功的关键是他们对自己所做的每件事情负责，关于这一点，我们将在 "我的源码让猫给吃了" 中加以讨论。因为负责，注重实效的程序员不会坐视他们的项目土崩瓦解。在 "软件的熵" 中，我们将告诉你怎样使你的项目保持整洁。
大多数人发现自己很难接受变化，有时是出于好的理由，有时只是因为固有的惰性。在 "石头汤与煮青蛙" 中，我们将考察一种促成变化的策略，并（处于平衡的兴趣）讲述一个忽视渐变危险的两栖动物的警世传说。
理解你的工作的语境的好处之一是，了解你的软件必须有多好变得更容易了。有时接近完美是唯一的选择，但常常会涉及各种权衡。我们将在 "足够好的软件" 中探究这一问题。
当然，你需要拥有广泛的知识和经验基础才能赢得这一切。学习是一个持续不断的过程。在 "你的知识资产" 中，我们将讨论一些策略，让你 "开足马力"。
最后，我们没有人生活在真空中。我们都要花大量时间与他人打交道。在 "交流！" 中列出了能让我们更好地做到这一点的几种途径。
注重实效的编程源于注重实效的思考的哲学。本章将为这种哲学设立基础。
第二版
第一章 务实的哲学
一个务实的程序员能够透过问题表面，将问题放在更宽泛的上下文综合考虑。
了解当前项目的来龙去脉，有利于把握项目接下来的发展脉络。
要做到以上几点，要大量的知识和经验。
人生是你自己的，是你在拥有、经营和创造。
在自己的职业发展、学习教育，以及项目和每天的工作等方面对自己负责，对自己的行为负责。
团队需要能够信赖我，我也要信赖团队里的每个人。
我想承担责任意味着我对这件事很是认同，保证能够完成，并做出承诺。我还必须分析超出我能力的风险情况。
如果责任并不明确，或是风险过大，都有权不承担责任。
不要把问题归咎于其他人，多想想自己能做什么。
提供选择，别找借口。
别害怕请教别人，别害怕承认自己需要帮助。
在说“我不知道”后，一定补上“------但是我会去搞清楚”。
软件的熵------软件的混乱程度。
负面情绪容易传染。
不要放任糟糕的设计、错误的决定、低劣的代码不去修理。
First, Do No Harm.
软件开发过程中，对应急问题的处理办法，不要干扰正常代码的运转。
项目协作：知道如何“借来”资源。找到合理需求，不断完善，一旦有成果的展示给大家看，这时可以说“当然了，它可以更好，只要我们再加点......”这句话。
持续审视身边和整个领域发生的事情，不要只专注自己在做的事情。
构建够好即可的软件。
投资知识，收益最佳。
知识组合：程序员了解的有关计算过程的事实、工作的应用领域，以及所有经验。
构建知识组合：
- 定期学习新知识。示例，每年学习一门新语言、每月读一本技术书、读非技术书、上课、加入本地用户组/交流群、尝试不同编程环境、与时俱进\
- 拓宽知识边界。别人的每次提问都是一个学习的机会。\
- 不要学习即将淘汰的技术\
- 在新技术流行以前开始学习\
- 评估哪些技术在未来前景更好
批判性思维：不要让自己的大脑成为别人思想的跑马场。
几个和批判性思维相关的问题：
- 问“五个为什么”\
- 谁从中收益\
- 这件事发生的背景是什么\
- 什么时候在哪里可以工作起来；当它结束后还会发生什么\
- 为什么是这个问题
交流很重要。作为开发人员，必须在多个层次上进行交流：
- 开会与老板同事交流\
- 和最终用户交流，理解他们的需求\
- 编写代码与机器交流\
- 编写文档，与下一个阅读文档的开发者交流\
- 写建议和备忘录，用于资源申请、报告现状以及提出新的解决方案
了解听众，明白自己想说什么，选择时机，根据听众调节表达方式，让它看起来不错，让听众参与进来，做倾听者，回应别人，把代码和文档绑在一起。
网上交流，特别是电子邮件，同样需要注意以上几点，一些建议：
- 点击发送按钮前先校对一遍\
- 检查一遍拼写，找到有可能是自动纠错没做对的地方\
- 用简单的格式\
- 尽可能少地引用原文\
- 如果要引用别人的邮件，一定要注明出处，而且是内联引用（不是放在附件里）\
- 不要在网上侮辱别人\
- 在点发送前，检查一下收件人列表