By Max Kanat-Alexander
做程序员的一定要时不时地读一些 easy reading，尤其是不需要做算法、操作系统那些高深东西的，多出来的脑细胞应该想
"All of us have been taught that software is “a series of instructions given to the computer,” and this is true. However, there is no field in which a set of instructions and the result of those instructions are so closely linked as they are in the field of software development. In other fields, people write instructions and then hand them off to others, often waiting a long time to see them carried out. But when we write code, there is nobody between us and the computer. The result is exactly what the instructions said to do, without question. The quality of the end result is dependent entirely upon the quality of the machine, the quality of our ideas, and the quality of our code. "
之前也很困惑为什么做软件不能像传说中的 engineer 那样，搭座桥建座楼，一百年不倒。 Chicago 的房子都是百年以来修修补补的。不过按书里的说法，这个反馈太暴力了，出一点儿错都不
“Everybody who writes software is a designer.
However, this does not mean that design is a democracy. You must not design by committee. The result will be an actively bad design—one which makes things more complex instead of simpler. Instead, all developers should have the authority to make good design decisions in their own areas. If they make poor or mediocre decisions, these should be overridden by a senior developer or the lead programmer, who should have veto power over the designers below them...
A designer should always be willing to listen to suggestions and feedback, because programmers are usually smart people who have good ideas. But after considering all the data, any given decision must be made by an individual, not by a group of people.”
"The purpose of software is to help people"
(从 stakeholder 角度看这句话，那这句话算是公理了。)
“The most common and disastrous error that programmers make is predicting something about the future when in fact they cannot know.
...there is a difference between designing in a way that allows for future change and attempting to predict the future”
我最喜欢这一段，因为自己经常犯这样的错误，眼高手低。另外这一段还可以为 code refactor 辩护。既然 code change 可能带来 side impact，为什么要做？因为 bad smell 就在那里。长久以来的经验告诉我，感觉会出问题的地方，那就一定会出问题。因为这种代
我也对变更记录很感兴趣，但是 so what？必须有足够长的历史数据，才可以证明代码的质量是上升了还是下降了。然而数
“Don’t write code until you actually need it, and remove any code that isn’t being used.
That is, you should also get rid of any code that is no longer needed
Code should be designed based on what you know now, not on what you think will happen in the future.
Here’s how we would use it to develop a calculator program that needs to add, subtract, multiply, and divide:
1. Plan a system that does only addition and nothing else.
2. Implement that system.
3. Fix up the now-existing system’s design so that it is easy to add a subtractionfeature.
4. Implement the subtraction feature in the system
In general, you should pick whatever is simplest to work on at each step, when you get there.”
Do not repeat yourself
"The ease of maintenance of any piece of software is proportional to the simplicity of its individual pieces."
“if people are new to something, they probably don’t know anything about it.
(Emacs vs. Vi) ... the perceived simplicity of a tool has to do with familiarity—anybody who has used a particular tool for a long time has likely become very familiar with it, which makes it much simpler than any other tool, from that person’s viewpoint. In order for a new tool to seem equally simple, that tool would have to be extremely simple, and programmers’ text editors rarely are.
Non-programmers would likely consider both text editors to be complex beyond reason, which is another example of how simplicity is relative.
Many programmers are particularly bad about this with their code. They assume that other programmers will be willing spend a lot of time learning all about their code, because after all, it took a lot of time to write it! The code is important to them, so won’t it be important to everybody?
Now, programmers are generally an intelligent bunch. But it’s still a mistake to think, “Oh, other programmers will understand everything I’ve done here without any simplification or explanation of my code.” It’s not a matter of intelligence—it’s a matter of knowledge. Programmers who are new to your code don’t know anything about it; they have to learn. The easier you make it for them to learn, the faster they are going to figure it out, and the easier it will be for them to use it.
... None of us like being talked down to or treated like we’re idiots. And sometimes that leads us to create things that are a little complicated, so that we feel like we aren’t talking down to the user or to other programmers. We throw in some big words, make it a
little less than simple, and people respect our intelligence but feel kind of stupid because they don’t get it. They might think we’re way smarter than they could ever be, and that is kind of flattering. But really, is that helping them?”
我极其喜欢这一段。知道对方不理解，是因为 knowledge 不够，因而需要理解对方的困难，这样就不会苛求别人。反过来自己也可以不用怀疑需要继
最近经常遇到 perception 这个词，因为比起谈人生、理想、情感，这个词听起来比较科学。一个人总会有自己的 frame，不乐意做什么、做不了什么，是有解释的。只要能解释就好。
谈到关于 vendor lock-in，这个也是选择 Open Source 的理由。因为不会 worse off，所以大家都会选同样的软件，所以最终大家都不会被 vendor lock-in，反而可以共同达到 better off
“Never stop maintaining a system that is currently in use so that the programmers can rewrite it. Systems must always be maintained
if they are in use”
谈到 long term development。这个呼应第 2 章，因为软件是给人用的。对 Open Source 的要求可以低一些吧。。毕竟资源实在太有限了，所以 LTS 很难搞下去，不管是 Fedora 还是 GNOME，甚至 Android，都是最新版的才有最多 support，旧版直接放弃的。