首先是第一章，书中例举出了从小孩玩的纸飞机，到“飞屋”，到莱特兄弟的飞机最后到我们看到的飞机。我想到的是，有的人从兴趣出发，觉得某些项目也好，工程也好，需要去实现。有的人放弃了，止步于纸飞机，有的人坚持了，做出了航模，到最后，有人成功实现了飞天梦。但是如果一开始这条路就走不通呢？就像永动机一样，很多人去尝试，认为这个装置将会有划时代的意义，但是到最后却被证明了这是不可能存在的。那之前的那些努力还是值得的吗？拿出来到软件行业，我也经历过一次科研立项，我的队友们一起想了很久关于项目最终要如何实现的问题，结果初期评审之后，换来的只不过是：“别看这个项目没什么用，但是它做不出来啊”。一次次的尝试甚至可能会看到进展，甚至是突破性进展之后，依旧发现项目是不科学的，不可能的。这个时候，到底应不应该放弃？是应该一开始就放弃，还是撞了南墙再回头？还是说我就是头铁，就是要做出来，做不出来也要实实在在地证明给所有人看，这个真的做不出来？
到了第一章的最后，关于 bug 和 feature 的讨论，我想是不是可以说明软件的开发者首先要是一个符合大众的软件的使用者？才能明白我为什么要做这玩意，做出来是为了干什么？
关于第二章，接触到了一个新东西——单元测试。书中讲了一些单元测试的必要性、由最了解代码的人来写单元测试的理由等等。因为之前并没有接触过单元测试这种东西，确实有些陌生，但是也实实在在地理解了至少从优化难度来看单元测试是很重要的一环。（关于单元测试https://baike.baidu.com/item/%E5%8D%95%E5%85%83%E6%B5%8B%E8%AF%95/1917084?fr=aladdin）
个人感觉经历了第二章之后，我们应该学会的是反思。不光从心理上反思，代码的反思也很重要，测试自己的代码有没有画蛇添足，有没有南辕北辙。
第十六章，关于创新。看了一章之后，我觉得，对于创新而言，可能这一行业的很多专业人物，或者一些常年接触这一行业的人，所谓“司空见惯”或者说“屡见不鲜”可能对这一行业的一些不便，或者弊端熟视无睹，因为遇到这种常见困难可能他们可以轻松地解决。但是对于一些“门外汉”来说，这些问题可能就会显得很麻烦，让人特别不爽。于是一些“不太懂”的人却能引领创新。
但是我依旧有第一章的问题，正是因为这些人并不是很专业于这些问题，在创新的过程中可能会费尽心血去解决一个曾经被证明解决不了的问题，这样有意义吗？在创新遇到困难时，到底怎样做才算理智？或者说应不应该理智？毕竟不管是书中列举的还是为人熟知的，很多成功的，很多创新成功的案例实际上不怎么理智如果所有人都“理智地创新”的话，又哪来的“创新成功呢”？
此外，关于“卫星电话”这个例子，我同样感觉到了反思的重要性，以及“软件的编写者首先要是一个符合大众的使用者”这一道理。很多无用功是怎样产生的，很多失败的创新是怎样做的，由此可见一斑。