这本书是老师推荐的一本书，后来，我到图书馆借了这本书，本来觉得应该又是一本专业书，无聊透顶，但是为了完成老师留的作业，也只能硬着头皮看下去。没想到，翻开书，发现这本书读起来很顺畅，不用像一般的技术书籍，晦涩难懂，枯燥无味，反而可以当小说看。
《梦断代码》向我们展示了硅谷一流软件开发者是如何进行产品开发的，把真实的人、事、技术以及产品的发展过程结合在一起。Discuz！的创始人戴志康先生说到：“软件开发者不是堆砌代码的工人，也无法安于命令式的任务布置。这些天才开发者们，低调、寡言、有独立的自我意识，他们并不迷恋于成为焦点的感觉，但却十分沉迷于自己认为伟大的创造。天才们在一起的合作，貌似创意无穷，实则合力有限；貌似独当一面，实则整合艰难。等等诸多问题，似乎成为了很多国内外软件企业的通病。”
翻开正文的第一页，你会惊奇的发现，标题竟然是“第0章”，别的书籍都是从1开始，为什么这本书这么奇怪，却是从第0章开始的。怀着这种疑问，我开始读这本书。读完第0章后，觉得这本书甚是有意思，读起来就像是读小说一样。而且作者也做出了解释，为什么以“第0章”开始，因为程序员是从0开始计数，而不是从1开始。而为什么程序员从0开始计数呢？因为计算机从0开始计数，所以，程序员也训练自己从0计数，以免让他们要指示操作的计算机产生误解。
在第一章中，描述了程序员之间讨论关于软件缺陷列表、软件时间问题的工作场景。提到了“布鲁克斯法则”：向已延误的项目中补充人力，只会使其继续延误。作者犀利的指出：这条法则常使程序员和开发经理陷入狼狈的境地，他们宁愿装作法则并不适用于自己，也不肯与之妥协。诚然，我们自己在编写程序时，通常都是乐天派，我们认定每个缺陷都可以被迅速修正，且修正旧缺陷必能减少新缺陷的数量。这种盲目的乐观，加上我们想要尽快的完成项目，往往让进度在一开始就偏离正轨。实际上，在实际开发中，编码只占软件项目开发时间的1/6，有一半的时间用于测试和修正缺陷。
在关于“人月”的问题，所谓“人月”，指一种科学管理概念，它假定生产力可被拆分为不连续、无差异、可替换的单元。所以，如果100人能在一个月内完成50个部件，则单位部件需要2个人/月。而布鲁斯卡尔观察到：“只有在任务能分派给许多互相之间无需沟通的工作者时，人和月才是可互换。”