语言只是工具。这句话就如同一同凉水一下泼醒了我这个自以为学的还不错的人，突然意识到就算现在的课程学的再好，做题的模式掌握的再熟练，考试分数拿的再高，但如果你并没有真正理解代码下的真正含义，这一切都是徒然。解决一个问题的语言可能有成千上万种，解决这个问题的方法也许也会有很多种，但是它们的理念却基本是一样的，所以语言只是你用来表达内心解决方法的工具，一门语言学的再好只能让你表达的淋漓尽致，却不能让你学会解决问题，所以我们应该更多的把重心放在如何解决问题以及解决问题的方法。就像捕鱼一样，用的是钓鱼竿或者是渔网都是一样的。重要的是最终有没有达到目的，而不是用的什么方法。
过程。过程伴随工程而生，它将工程分解开就有了角色，有了角色就有了沟通。项目经理在开发的过程中，不能给客户留下太多的“憧憬”，要清楚的了解那个环节更加重要。角色的确定以及沟通显然十分重要。不能被uml遮蔽住眼睛，应该多与客户，开发人员进行有效的交流。
工程就是将某个（或某些）现有实体（自然的或人造的）转化为具有预期使用价值的人造产品过程”。就广义而言，工程则定义为由一群人为达到某种目的，在一个较长时间周期内进行协作活动的过程。
工程。工程就是对目标的描述和成果的检验。很显然，软件规模的不断增大是工程产生的根本原因。项目的复杂导致只有更多拥有多方面知识的角色参加才能解决问题。所以团队意识在项目实现中就显得更加重要。
组织。工程理论其实是包括组织学的，项目经理除了关注技术问题外，必须更关注于对这个工程的组织与计划。把技术问题留给开发经理，或者留给体系。需要做好很多个人以及整体员工的分工，安排。不能因为是老板犯的错就可以宽容，而员工却不行。重点在不能失去员工的信任。
软件工程是实践中摸索出来的方法论。每个组织的大小、行业、具体情况都很不一样，更不谈人员组成、企业文化、客户的不同了。这样每个组织都应该找到适合自己发展的软件工程的方法和过程。软件项目需要在时间、资源和功能中找到平衡，如果一个目标本身都是有问题的，软件项目注定着会走向失败。而如果项目进度和工作量评估不靠谱的话，就更是雪上加霜了。目前公司的项目都或多或少的存在着这样的问题，然而我们真的学会了“折中”吗？我们继要应对快速的变化，又需要保证系统的安全可靠和高可用性。这是我们现阶段最需要解决的难题，体制问题和认得问题真的很难严格划分。