《列子.说符》中说：“得其精而忘其粗，在其内而忘其外；见其所见，不见其所不见，视其所视，而遗其所不视。”这句话是说：得到了它的精微,而放弃了它的粗略,省察其内部而忘却其表象,看见了他所应当看见的地方,而没有看见他不必看见的地方,考察了他所应当考察的地方,抛弃了他所不必考察的地方.
我现在大二，已经学习了c++，java等编程语言。不知道有没有人思考过这样一个问题：“语言”到底是什么？这听起来有点可笑，但是我们又给不出一个明确的回答。《大道至简》的作者向我们揭示了答案：语言是一种工具。不管是哪种语言，都可以相互转换，只要你都懂，因为它的精髓都是一样的，只是用不同的方式表达了出来。就好比英文和中文的关系。
学习编程的人都知道，“程序=算法+结构”，这是编程的本源定义，也是原始的状态。与代码相关的任何工作，最终仍旧会落足于这样的一条规则。编程的精义于此。从有开发行为开始，它就存在了。愚公在数千年前就在用这样的行为做工程了。基于这样的定义，我们还需要方法。长期的编程实践，自然的归演与总结，必须沉淀为某种（软件开发）方法，于是“过程”出现了，于是“对象”出现了，于是相关的方法论也就出现了。这是实践的结果。
所以说，方法不是某个人或者某个组织创造的，而是实践的不断积累，最终促使某种方法诞生了。然后，这个方法就开始被大家所共用。
正如“模式”是一种方法，而模式就是你昨天书写代码的那个行为。你看不到你做事的行为，也就不能理解“模式”作为一种方法的价值。所以，大师们众口一词：模式需要一定的编程经验才能理解。同理，理解过程也需要编程经验，，理解对象也需要编程经验，理解MDA和SOA还是需要编程经验。
那经验从何而来？经验来源于你对上一行代码或上一个失败程序的回顾、理解与分析，而不是你将要写的下一行代码。
工程一定伴随着过程。过程解决的是工程中角色间的关系问题。做一项工程，我们首先要将它分为几个环节，有了环节，就有了角色，然后就有了沟通。换句话说，过程中的问题，就是角色、沟通和环节的问题。
有了过程，我们再来说说工程。工程简单地说就是描述“做什么”和“做到什么”。那么工程是因为什么而出现的呢？随着软件规模的不断增大，项目的“复杂”可能要求不同的知识领域的角色参与。那么“团队”作为开发行为的模式，是软件规模和复杂度渐次积累的结果。由此，工程就出现了。
工程理论其实是包含组织学的。组织，包括人力资源、项目资金以及多个项目间的协调等，是由向项目经理负责的。他需要为项目的各个阶段建立计划，并逐渐地细化计划内容；需要确立项目或产品阶段目标，成果的准确描述，定位，以及整个项目的质量目标及其评核办法；需要对团队中的不同角色培训，指导，并协调他们的工作；还需要为每一个人准备他所需要的资源等等。总之，组织者的工作都是非技术性的。而Boss并不是组织者而是经营者。