做项目，不仅仅是要求的从细节之处着手，更重要的是要学会从大局出发，正所谓“得其精而忘其粗，在其内而忘其外；见其所见，不见其所不见，视其所视，而遗其所不视”就是这个理。
很多时候，我们往往在语言上花费更多的精力，却不知道，其实语言只是工具而已。如果你还在像大多数开发人员一样热衷于争论语言孰优孰劣，那么，你其实是很可悲的。其实我们更需要做的就是从现在开始好好认清代码、方法、过程、工程与组织之间的联系。
工程最核心的就是程序=算法+结构，这也是一个工程的最原始状态，与代码相关的任何工作最终都会落足于这样一条规则。这个编程精义从程序开发开始便存在了，程序的开发人员在这种逻辑中打转。
在长期的编程实践中，通过自然的归演与总结，沉淀出一种软件开发方法，于是便出现了方法论。这种方法是实践的结果，它并不是由个人或者组织创造的，当实践积累到一定程度，就会有人或者是组织提出这种方法，这是一种必然。所谓的模式不过就是归纳、抽取、提升了书写代码行为的内在规律。在没有一定的编程经验的情况下，这些模式看起来似乎有点难以理解，但我们仍然要积累经验，这种经验来自于回顾、理解与分析，而不是将要写的下一行代码。
过程似乎是与工程相生相伴的，过程是解决工程中间的角色间的关系问题。
过程中的问题通常是角色、沟通和环节的问题。，你看到的是他们因为你做的项目的一再延迟而懊恼，沮丧甚至是愤怒。在产品开发的过程中，要分清玩家与客户的区别，不要是工程一再的延期，这样即使项目做得再好，项目需求方也会因为时间问题而被拖死，客户不会因为技术你对技术的描述而憧憬。
我们常常会看到“合作无间”几个字，其实真正的“无间”应当是沟通的结果，沟通出问题可能会导致整个项目的拖延或失败。
在狭义的工程里，工程师对目标的描述和对成果的检测，而这个目标的实现则是“过程”和“方法”的事，快速实现这两者的是工具。软件工程被称为几个层次，分别是工具、方法、过程、实现对象。通常来说，项目是复杂的，可能要求不同的知识领域的角色参与，也要更多的人力、技术与管理资源来支持。所以作为软件规模和复杂度渐次积累的结果的团队就出现了。在未来，软件规模越来越复杂，造成了团队的不断扩大。
工程理论包含组织学，这就要求项目经理必须关注人力资源、项目基金以及多个项目之间的协调等问题。作为项目经理，要注意回顾每一个项目，或者说项目的每一个阶段以及与每一个团队成员交流的细节，发现问题，寻找问题，解决问题。
在软件工程体系中，“实现”作为软件开发的本质需求和基本动因，如同上帝之手在推动软件工程理论体系的形成。