软件时间从0计数，做项目之前需要有一个蓝图来规划项目的进度，在项目期间会出现黑洞式的缺陷—即无法确定修正所需时长的缺陷。而如果项目已经延误，再往里面补充人力，只会让它继续延误（布鲁克斯法则）。制作软件的大量工作受困于“序列约束”，它限制了任务分解的程度：该模块可能是其他模块完成的先决条件，这个问题派多少人也不能解决。而最完美的软件开发就是一个人工作，根据自己的计划，依次实现各个功能模块，但是在现实中必须学会团队分工合作。
在项目中，只要有足够多的beta版测试人员和开发者队伍，几乎所有的问题都会很快被发现并解决（李纳斯法则）。
对于创造性的工作，玩耍是最经济有效的模式。在现在来说，只有顺应时代的发展、顺应大众的要求去做项目，去创新才能被人们广为接受。
计算机产业，失败的案例总是被遮盖、被忽视并且/或者被说成是合理的。最终结果就是我们一直重复着相同的错误，而不会有人去探究前人失败的经验，分析他们失败的原因，而这些失败者也不会去思考究竟是为什么失败，下一次依旧重复这一次的经历。然而如果太在意那些失败的经历，很可能一行代码也写不下去。
编译型语言指编译器将程序员源代码翻译成机器可读的二进制代码后再运行；解释型语言指解释器逐行翻译源代码，再让处理器运行。解释型语言的效率较低但是较为敏捷。
一个软件可以分为“前台”和“后台”。前台是程序中和用户打交道的部分，他需要有强大的功能，直观；后台是前台发生的时间和用户输入流向的地方，计算机对事件和输入进行处理、保存和取回，它应该是隐形的、高效的、强固的。
1、我过去是怎么做的：做团队项目时没有很好的计划，计划哪天该做什么，但还是按照自己没有计划时的节奏走，一直拖拖拉拉；对软件并没有好好的做测试，；出现漏洞之后没有很好的分析这个漏洞到底是什么原因导致的。
2、结合书中所讲，说明为什么这样不好：不能在有效时间内更好的实现目标；每次安装新版本之后没多久就可以找到软件的很多漏洞；没有分析漏洞原因，就会导致其他有相同漏洞的地方不能有效的被避免。
3、提出一个解决办法，避免再次掉入陷阱：有精确的计划，严格按照计划走；软件要多做几次测试找bug，找到bug后要分析原因，然后解决相同或相似bug。