从编程到工程
第一节——语言只是工具
本节开头讲述了作者以前的样子，跟大多数程序员一样，专注于写代码，并对编程语言有偏见，非要比语言之间的孰好孰坏。但慢慢地，作者变了，变得不再执着于编程语言的孰好孰坏，认为语言只是工具。这个转变是由于，2014年3月，作者受邀参加“Delphi & Delphi . NET源码分析”的专题培训，花了两周的时间准备PPT。在最后临行前的写完，作者反复思考一个问题：我究竟做了些什么？或者说，我究竟想告诉学员些什么？思前想后，在凌晨五点，在PPT的末尾加了一张幻灯，标题便是“语言只是工具”。从这刻起，作者便才真正地知道工程。
我们不要执著于编程语言的孰好孰坏，也不要纠结于某个代码实现的细节，语言只是编程的工具，我们只需好好利用，不必过分去纠结细节。
第二节——程序
“程序 = 算法 + 结构”是编程的本源定义，也是最原始的状态。这还是编程的精义。
第三节——方法
推动逻辑向前发展的是“方法”和“方法论”的出现。“方法”是实践的成果，是由长期的编程实践，自然地归演与总而来的。只要实践积累到一定的成度，“方法”就会自然而然的出现，并不一定是由一些软件大公司、软件大能提出来的，也许他们没提出来，但你却正在使用。理解方法或注意到自己正在使用却没人总结的方法是需要编程经验的，而编程经验来自于回顾、理解于分析，不是来自于你将要写的下一行代码。
编程需要总结，需要回顾，需要理解。只有这样才能增强自己的编程能力。
第四节——过程
在项目开发的过程中，需要解决角色、沟通和环节的问题。哪些环节重要取决于具体的编程行为，也就是具体的项目。有的项目追求品质，可以一再拖延，但大部分的项目却追求的是及时完工，所以，为了避免看到客户的暴怒，项目经理要会识别客户的侧重点，尽量满足客户。。角色的确定，以及角色间的沟通问题，在项目过程中也是同样重要。团队之间相互的协作紧密，是项目成功的保证。而这一切都与沟通有关，良好的沟通是一切的基础
第五节——工程
最狭义的工程是指对目标的描述和成果的检测。软件规模的不断增大是导致工程出现的根本原因。复杂的项目要求不同知识领域的人参与，并且需要更多的（人力。技术与管理）资源。“团队”作为开发行为的模式，是软件规模和复杂度渐次积累的结果。越来越大的团队需要的是高度过程化、通晓方法理论和大量工具。
第六节——组织
项目经理必须更加关注于工程的组织与计划，可以较少的关注与技术有关的管理技能（需求、配置、过程管理等）。因为那些可以交给开发经理来做。项目经理必须组织协调好项目开发的各个阶段，尽力去激励团队成员，使他们尽力开发，给他们配置良好的工作条件，不要保持乐观，尽力去避免重复犯错，以及避开那些可预见的错误。争取团队成员的信任比争取老板的信任更加重要。
组织经理的日常工作是回顾每一个项目，或者项目中的每一个阶段，以及与没一个团队成员交流的细节。
第七节——BOSS
BOSS并不决定你的薪水。与薪水有关的角色是部门/团队经理、纪效经理以及财务经理。BOSS是决定公司的方向，组织者保证决策与这个方向是同步的，而工程是在这样的一个方向、决策构架下的一个具体行为。工程中没有BOSS。
第八节——上帝之手
软件行业的各种开发工具、各种结构、各种模式等等，都是由软件开发的本质需求所决定的。总之，软件行业一切的一切都是以实现现实中编程的需求服务，都与它相关。