这本书第二部分讲的是文化，对于技术人员来说稍微有点无聊，不过决定我们在一家公司工作舒服不舒服的，其实主要就是这些文化内容，如果用这一部分里的内容去考核那些我们日常工作中的人，可能结果也会令人失望。
这一部分的内容可以看出 Google 和国内公司的文化有巨大的差异，对国内的工程师和 manager
来说，有一些思想有借鉴意义，而另一些只当参考即可(全信的话，你一定会被坑得很惨)。
软件开发要依赖团队协作
Google 内部的代码管理系统收到过很多人的需求，希望能把项目设置成
private，这个需求来自于很多人在项目写完之前，不想让别人看到自己的代码，这种心态是由于研发人员的不安全感。比如他们可能害怕：
* 别人嘲笑你，这样的错误你都犯，和你的工作年限是不是匹配啊，可能你其实是个菜鸡
* 明明是自己想出来的 idea，但是最终却被别人抢去邀功了
对代码的“
这个是这本书的读书笔记，这本书总共有四个部分。
第一部分只有一章，所以可以水一篇，开心。
第一部分：论题
什么是软件工程
软件工程是随着时间的推移不停地对代码进行集成(Programming integrated over time)，这本书将软件项目分成两种，一种是
programming，一种是 software engineering，具体的区别：
* programming 指短期任务，比如一次性的脚本，一次性的算法题目，学校里的项目等等；一种是 software
enginnering，要考虑你的项目要长期存活，所以要认真地考虑“时间”这个要素对软件本身的影响。
* SE
每过一段时间，就会有人跳出来批判 DDD，这东西到底是垃圾还是银弹？
在某某公司干活的时候，有一批人声称要用 DDD 改造老旧系统，彻底解决核心流程规模化之后，项目难以维护的问题。之前某篇文章里的这张图，就是在用 DDD
做项目重构之前的烂摊子：
大家都很聪明，聪明到最后没人知道这新需求到底该往哪里写了。架构师们聚在一起学习 DDD 精神，产出学习报告，大半年过去，终于出了一些成果，有些子项目完成了用
DDD 进行的重构，年底可以拿来在酒会上邀功了，这下我们跟上了业界业务开发的主流方法论，可喜可贺，可喜可贺啊。
年末的时候部门内匿名提问的小纸条却向架构师们发直球：“为什么用了 DDD 以后，
之前写过文章讲工程师应该怎么学习，讲的最多的就是要多读体系化的技术书籍。最近碰到一些朋友说读书读不进去，读的太慢，或者读完就忘该怎么办。
这篇文章解答一下这几个问题：
* 读书读不进去
* 如何加快阅读技术类书籍的速度
* 读过的书会忘记怎么办
读书读不进去
读技术书主要有两个目的，一是和工作内容结合寻找能够落地的方案，二是了解不太熟悉的领域的宏观大图，帮助自己建立知识体系，拓宽视野。
能直接和工作内容结合的书是最好的，如果我们在做流式计算领域，那把市面上常见的几本英文书：《stream processing with flink/spark》
和 《streaming systems》读完自然是应该的，书的内容和我们的工作密切相关，这种类型的书不太可能看不进去，如果看不进去，就看看自己的银行卡余额。
若是想拓宽视野，阅读的内容大多就和我们的日常工作脱离了，
假期就不聊技术了。
《Stop Reading The News》 是一个 150
页的小册子，假期闲来无事，把它读完了。最初买这本小书的原因是看到了这么一个故事：作者受邀去英国的卫报(The Guardian)宣传自己的书《The Art
of Thinking Clearly》，卫报的编辑表示对作者 blog
上的批判新闻的文章更感兴趣，希望他能详细讲一讲(有股鸿门宴的味道啊)。所以作者在没有准备的情况下，头铁地现场陈述了新闻的种种罪状，并尴尬地在现场没有得到任何回应。
卫报的编辑们作为新闻媒体的从业人员，想必是不会同意作者的观点的，不过他们还是很神奇的，把它的观点汇总起来发表在了网站上：news
