Reading: More Joel on Software

Also known as More Joel on Software (Joel谈软件). Reading notes, just writing practice.

Why I Picked It Up

I first saw this book recommended on Limboy - A Short Note on “More Joel on Software”.
Ruanyifeng also has a post about it: Joel on Software has been published, and the comments there seemed positive too.

At first I just wanted to skim what the book was about, but it was so interesting that I kept reading. The author writes in a funny, lively way, and I laughed out loud more than once, for example in Chapter 25, where he pokes fun at Microsoft’s smug superiority.
Ruanyifeng’s translation is also smooth, and he added a lot of footnotes that help explain the English jokes.

More Joel on Software is not really a technical book in the strict sense. It’s more like an essay collection, gathering the best posts from Joel’s personal blog Joel on Software.
The author has a rich background: he once worked at Microsoft as a program manager on the Excel team. At Microsoft, a program manager is the person on the team with the strongest technical skills and enough charisma to lead people.
Halfway through I checked Wikipedia and found that he also co-founded Stack Overflow. Thanks, Joel, for making Ctrl C and Ctrl V possible.
The book does not have especially tight continuity, because it is a blog collection. Some things get repeated, but that is fine.

Books Mentioned

This book mentions a number of other books and people.
I’ll jot them down and put them on my reading list. (~~someday~~)

Peopleware, famous name, still not read
The Mythical Man-Month, even more famous (I have read this one: Reading: The Mythical Man-Month
MIT 6.001 Structure and Interpretation of Computer Programs, 1996 edition. The HTML full text is in Resources, along with video lectures

Now the notes begin.

Part 1: People Management

1 My First BillG Review

BillG review here means a review by Bill Gates.
In 1992, the author was a program manager on the Excel team at Microsoft, responsible for an important feature.
Before the review, he was checking his submission for mistakes and noticed that Excel and Basic handled date and time functions differently, because Excel had to stay compatible with Lotus formats at the time.
At the review the next day, he found that Bill Gates had written comments on every page of his 500-page submission from the day before.
Gates’s questions got harder and more detailed, until he finally asked about a tiny detail in the date and time functions. The author answered, and Gates ended the questioning.
The author concludes that you should never try to bluff Bill Gates, because he is a real programmer and his technical knowledge is astonishing.
He also takes a jab at Lotus: running a software company without understanding programming is like trying to surf without knowing how.

2 Finding Great Programmers

The author argues that the best programmers never show up on the job market.
They are so good that they already get recommendations from professors before they even graduate.
If they do leave, it’s because they are starting a company or moving on, and they can pick the jobs they want. They don’t need to send resumes around.

Given that, his advice is:

Go out into specialized technical communities and conferences to find talent.
Interns: his own company reaches out through many channels to college students who are one or two years away from graduating, and offers them excellent internships in order to attract talent early.
Build a community. His own blog has as many as one million readers, though that kind of approach is hard to replicate.

He also warns about employee referrals, because of non-compete clauses or because people may recommend others recklessly just to get referral bonuses.

3 A Practical Guide to Finding Great Programmers

If top programmers don’t lack job options, then the key is making your job attractive to them.
The author offers a few suggestions:

Private offices
Higher efficiency, and people feel valued.
The work environment
Keep the office clean and bright, and the surroundings well-equipped and pleasant.
Toys
He means the programmer’s work tools: big monitors, large desks, and the freedom to order technical books.
Programmers’ social life
How the company treats programmers: are they treated like screws in a machine, or like core contributors?
Smart, friendly coworkers.
Independence and autonomy: give smart people the work and respect their domain expertise.
No politics
Avoid toxic politics. Many people choose programming because they would rather spend their time in a fair and orderly environment, where code either works or it doesn’t.
What kind of work am I doing?
Programmers like work that feels interesting and cool.
Oracle’s approach was to let top employees choose the projects they wanted.
You can also let programmers use interesting new technologies on things like internal tools or non-critical new programs.
Can I identify with the company?
The meaning of the work, open source, free software, non-profit causes, and a positive brand image can all increase identification with the company.
One thing programmers don’t care about
Besides the positive factors above, the author also says programmers do not care as much about money as you might think.
As long as compensation is basically reasonable, salary is much less important than the factors above.

A pretty idealized work environment, but Joel did later found Fog Creek Software and put some of it into practice.

4 Three Management Styles

Everyone in a company has their own private goals. The question is how to align them so people mostly pull in the same direction.
In the next three chapters, the author discusses three general management styles and their strengths and weaknesses.

5 Military Management

A very common management style, with obvious flaws.

Smart people, or most people, do not like being ordered around.
Military-style management is hard to micro-manage.
In an army, a commander gives an order and a whole line of soldiers runs thirty laps.
In a company, though, everyone has a different role and different responsibilities, so a manager rarely has enough time or energy to manage each person carefully.
That often turns into a hit and run style of management.
In high-tech companies, the people doing the work know more than the leaders, so they are the best people to make the decisions.
The author says that when he was at Microsoft, Mike Maples refused to opine on technical issues and instead gave programmers the authority to decide technical solutions.

6 Incentive-by-Money

In simple terms, this is about setting KPIs and using financial rewards.

The downside is that it turns programmers’ internal motivation - I want to write good code because I want to do great work - into external motivation - I want to write good code because I like money and want a bonus. That actually reduces their desire to do excellent work. If the bonuses stop, they stop caring about code quality.

Another problem is that programmers, or any employees, start gaming the system, looking for loopholes or exploiting flaws. In the end it becomes a cat-and-mouse game between the rule-makers and the programmers.

The author thinks the biggest problem with incentive-by-money is that it is not management at all; it is management stepping aside, a cleverly designed way to dodge responsibility.
It shows that management does not know how to guide people toward better work, so it leaves employees to figure things out on their own within the rules.
For code, the right approach is to train employees and improve their programming skill, not just throw money at them.

7 Identification

The purpose of identification is to create internal motivation.

On one hand, increase employees’ identification with the company.

If the company has a grand, noble goal, employees will feel proud of their work.
One method the author likes is eating together. He thinks it makes the company feel like a family and helps employees like the company more.

emmm, hard to judge.

On the other hand, you also need to provide the necessary information so employees understand the reasons behind company decisions. That helps everyone move in the right direction together.

Part 2: Advice for Future Programmers

8 The Danger of Teaching Only Java

On the chapter title, Ruanyifeng specifically noted this in his blog post Joel on Software has been published. I quoted it here:

The Chinese edition is called Software Reminiscences, with the subtitle Joel on Software, Chief of the Programmer Tribe.

Don’t ask me why they picked that name, because I don’t know either. It was the publisher’s decision, probably to attract more non-specialist readers.

Also, since the publisher had the final say, some sentence translations and article titles were changed, and there was nothing I could do about it. For example, the article originally titled “The Danger of a Java-Only School” is now called “The Danger of Teaching Only Java.” Different people will judge that differently.

At first glance, it sounds like the usual young people these days can't take hardship, back in my day... kind of complaint（笑.
But after reading it, the actual point is that Java is not hard enough to be a useful filter for selecting excellent computer science students.

The author says his view is no different from Latin advocates: Latin trains your mind and exercises your memory. Analyzing Latin syntax is the best exercise for thinking, a real intellectual challenge that builds logic well.
He thinks pointers and recursion are the Latin of computer science.

He also admits that in modern software development, most situations do not require pointers or functional programming.

But if you don’t understand pointers, you can’t even read a line of Linux code. If you don’t understand functional programming, you can’t build something like Google’s MapReduce.
More importantly, the real value of pointers and recursion is the depth of thinking you gain while learning them, and the mental toughness you build by being scared of these classes.
Pointers and recursion require a certain level of reasoning, abstraction, and most importantly, the ability to look at the same problem across several different levels of abstraction at once.
So whether you truly understand pointers and recursion is directly related to whether you are a good programmer.

The author mentions a few topics:

指针（pointer）
递归（recursion）
数据结构
不动点定理（fitxed pointer theory）
函数式编程（functional programming）
MIT 6.001 Structure and Interpretation of Computer Programs

9 A Talk at Yale

和上一篇内容有点类似，都是说课程内容足够难才能筛选出真正适合学计算机的学生

作者试听了一节 动态逻辑 课程就知道自己不是馆理论的料

When it comes to producing higher-quality code, the author divides the software world into two camps: geeks and suits.
Geeks use automation to improve software quality, for example unit testing, test-driven development, and automated testing.
Suits care less about quality; as long as the product can be sold, that is enough.

The author leans more toward the suits and gives two reasons:

Killing bugs in code is a diminishing-returns problem.
Once software quality reaches a certain level and solves real problems, that is enough if users are willing to buy it.
The geek definition of code quality is too narrow. Automation can verify that the code itself has no problems.
But things that cannot be tested automatically, such as whether the UI looks good or whether the interaction logic makes sense, are excluded from that definition.
The suits have a broader definition of code quality, because all of that affects whether the software can be sold.

The author warns about internal programmers, who make software for use inside the company and make up about 80% of programmers in the world.
They usually do not get to choose cutting-edge technology, and their products only need to be good enough to use, unlike commercial products that are constantly refined and improved.
On top of that, internal programmers are a cost the company has to carry, while the company prefers people who make money.
That means technical stagnation, declining taste, and no bargaining power. It is a very passive position.

The author believes that whether you can write clear technical articles determines whether you are a mumbling programmer or a leader, so writing ability is very important.

10 Advice for Computer Science Students

毕业前练好写作
毕业前学好 C 语言
毕业前学好微观经济学
不要因为枯燥就不选修非计算机专业的课程
选修有大量编程实践的课程
别担心所有工作都被印度人抢走
找一份好的暑假实习工作

Part 3: The Role of Design

11 Font Smoothing, Anti-Aliasing, and Subpixel Rendering

苹果的字体渲染方式更倾向终于字体的原始设计，即使有损清晰度也在所不惜
微软则倾向保证可读性，即使背离字体的原始设计

如果你问人们喜欢什么样的风格和设计，除非受过专业训练，否则他们一般会选择自己最熟悉的品种

12 Every Pixel Matters

做优秀产品需要「强迫症」一样的精神

为了发现可以改进的地方，你必须有一个思维定势，始终如一地用批判地眼光看世界
当你改正了一个又一个这样的小细节后，当你磨光、定型、擦亮、修饰你的产品的每一个小边角后，就会有神奇的事情发生。厘米变成分米，分米变成米，米变成了千米。你最后拿出来的是一件真正优秀的产品。它第一眼就让人觉得震撼，出类拔萃，工作起来完全符合直觉。就算 100 万个用户中有一个用户某天突然要用到一个他 100 万次使用中才会用到一次的罕见功能，他发现了这个功能不仅能用，而且还很美：在你的软件中，即使是看门人的小屋都铺着大理石地板，配有实心的橡木门和桃花心木的壁板。
就是在这个时候，你意识到这是一个优秀软件。*

13 The Trap of Big Ideas

这篇是作者对 Scott Resenberg 《梦断代码 (Dreaming in Code)》一书的评论

人们往往高估自己清晰判断事物的能力，总是觉得自己看到了全部，即使事实并非如此
在软件开发中，这种错觉会导致你感觉自己已经在头脑中形成了整体设计，每一步都清晰无比，这时立刻开始着手工作就会掉入两个陷阱：

对自己的设想过于自信
认为自己不需要详细的说明书，直接开始写代码就行

生活中也经常有这样的情况，例如写博客，感觉脑海中想法很清晰，但实际坐下来打字时不是抓不住头绪、无从下笔，要不然就是思路混乱、废话连篇
在做产品设计之前就开始雇佣程序员
世界上只有一件事比你自己设计软件更困难，那就是一个团队一起设计软件

《人月神话》贵族专制、民主政治和系统设计(Aristocracy, Democracy, and System Design) 一节也讨论了类似主题：为了保持概念完整性需要在设计阶段实行「贵族专制统治」，一群人开会做决定只会拖累进度、降低品质

14 Don’t Give Users Too Many Choices

太多的选择限制了我们的自由，而不是解放了我们

想到《天真的人类学家：小泥屋笔记》结尾主人公从非洲原始部落回到英国现代社会时的感受，选择过于丰富，就像被海量嘈杂信息淹没

作者讨论了如何将 Windows 中 15 种关闭计算机的方法精简成一种，思考过程非常有趣，建议看原文
微软和大部分开源软件都有这样的问题，菜单设计的大而全，往往过于繁琐

但总感觉苹果的理念是规定用户「你应该这样用」，如果自己的使用习惯恰好和苹果规则一致时很舒服，当你一旦想稍微偏离苹果的使用规则，那就抱歉了

15 Usability Is Not Enough

社会化界面工程学 (social interface engineering)
社会上存在各种各样的人，想占便宜的、搞诈骗的、为非作歹的，社会化软件里也存在这类问题
例如，如何应该在论坛里发广告的人？
一种办法是弹出错误信息，禁止发广告
另一种办法是假装系统接收了用户发送的广告，他觉得目的达成，就会转到其他地方继续发广告

16 Building a Community with Software

软件项目同建筑项目一样，设计规划非常重要，它能够决定在线社区的成败和它的类型。如果你让某个功能很容易操作，人们就愿意使用它。如果你让某个功能很难操作，人们就会避免使用它。通过这种方式，你能够暗中鼓励人们按照预想的方式表现，这决定了一个社区的特性和品质。
软件实现上的小细节会导致在线社区发展、运作、用户体验上的大差异。

最近看到一个视频，提到动画和真人电影的区别，金敏说 动画是从零开始，不带着意图就无法进行的创作，所以动画的每一帧都是经过设计的
这似乎和软件也有点类似，同样是从零开始的作品，作品中的每一个细节都反映了创作者的意图
想要做出什么样的软件？
想要传达什么理念？
希望用户如何使用这个软件？
这些都需要创作者自己心中有答案

这章内容里 Joel 对搭建高质量社区的一些思考值得一看

Part 4: Managing Large Projects

17 Martian Headphones

本章讨论 IE 7 升级 IE 8 过程中为了符合 Web 标准，理想主义阵营 (严格遵守新标准) 和 实用主义阵营 (兼容旧标准) 之间爆发的口水大战
最终结果是 IE 8 默认使用新标准，但同时提供 兼容性视图

18 Why Microsoft Office File Formats Are So Complicated (and Some Countermeasures)

稍微一窥 Excel、Word 的复杂性

回顾整个历史，程序员无时无刻不想做出正确的事情，但是有时候你不得不向现实屈服。

如果不得以要和 Office 打交道，作者给了两个对策：

让 Office 为你干脏活
用一种更简单的格式生成文件
生成 CSV 格式文件给 Excel 处理，HTML/RTF 格式给 Word 处理
而非想办法生成 Office 文件交给 Office 处理

19 If You Want to Make Money, Don’t Be Afraid of the Mess

解决轻而易举的事情是拿不到钱的

但在日本怎么经常感觉 这玩意儿也能卖钱？、这玩意儿也有人买？（

编写一个设计优雅、易于使用的应用程序，同解决「麻烦事」有相仿的效果。虽然看到成品的时候，你会觉得不难做，但实际上是很难的。就好比你在看精彩的芭蕾舞演出，你觉得演员跳起来很轻松，实际上换了你就困难无比。Jason 和他的 37signals 致力于做出优秀的设计，他们得到了回报。优秀的设计似乎是最容易复制的东西，但是做起来却又不是那么容易，你看看微软试图效仿 iPod 的例子，就会明白这一点。做出优秀的设计本身就是一件「麻烦事」，实际上能够提供牢固得令人震惊的竞争优势。

Part 5: Programming Advice

20 Evidence-Based Scheduling

如果日程规划是以「天」为单位，甚至以「周」为单位，我就认定它是没用的。你必须将日程规划先分解成一些非常小的任务，这些人物能够在以「小时」为单位的时间段中完成。不能有任何人物所需的时间超过 16 小时。

保留好工作时间记录单。让你用在每项任务上的时间长度留下可以追踪的痕迹。以后，你就可以回过头来参考这些数据，估计一下新的任务相对需要的时间。

只有第一线的程序员才能提出完成日期的估计值
一发现错误就立即修正，将用时算入原始人物的用时之中
防止管理层向程序员施加压力，要求加快开发速度

有效的日程规划有许多很大的好处，其中之一就是你会被迫删去一些功能
删掉容易做的，或是有趣的功能，砍到不能再砍的地步，只保留能够把产品变成真正优秀产品的重要功能

21 Strategy Letter VI

有一些程序员将大量经理投入优化工作，要将程序变得更紧凑、更快速。某一天，他们醒来后发现，这种努力基本上是白忙一场。
从长远的观点来看，那些不关心效率、不关心程序是否臃肿、一个劲往软件中加入高级功能的程序员最终将拥有更好的产品。

22 Can Your Programming Language Do This?

这章讨论 函数式编程 (functional programming)，下面是一些摘抄：

如果你不懂函数式编程，你就无法创造出 MapReduce，正式这种算法使得 Google 的可拓展性（scalable）达到如此巨大的规模。术语 Map（映射） 和 Reduce（化简） 分别来自于 Lisp 语言和函数式编程。回想起来，在类似 6.001 这样的编程课程中，都提到纯粹的函数式编程没有副作用，因此可以直接用于并行计算。任何人只要还记得这些内容，那么 MapReduce 对他来说就是显而易见的。发明 MapReduce 的公司是谷歌，而不是微软，这个简单的事实说出了原因，为什么微软至今还在追赶，还在试图提供最基本的搜索服务，而谷歌已经转向了下一个阶段，开发 Skynet，我的意思是，开发世界上只打的并行式超级计算机。我觉得，微软并没有完全明白在这一波竞争中它落后了多远。
好的，我希望到了这个时候，你已经深信不疑了。你确信，那些具备了 第一类函数 功能的编程语言，能够让你更容易地完成进一步抽象代码的任务。这意味着你的代码体积更小、更紧凑、更容易重复利用、更方便拓展。谷歌的许多应用程序都使用了 MapReduce 技术，所以一旦有人对底层的并行计算程序进行优化或消除 bug，那么所有这些应用程序都会受益。
说到这里，我有点动感情了，忍不住想站起来说，最优生产效率的编程环境是那些允许你在 不同层次上进行抽象 的编程环境。

看得出来作者非常推崇这种编程方法/思考模式，最近学习 JavaScript 和 Python 的过程中也接触到了一些函数式编程内容，似乎能理解原理，但如何在实际中运用函数式编程方法，特别是 如何设计程序 以满足函数式编程思想，这方面还完全不了解，也许以后可以找 Lisp/Haskell 这类纯函数式编程相关的书籍来看看

23 Make Wrong Code Obvious

作者讲述了程序员的 4 种境界：

你分不清什么是干净的代码，什么是不干净的代码。
你对干净的代码有一个肤浅的认识，主要看它们是不是符合代码书写规范。
你开始能找出那些很隐秘的不干净代码，在干干净净的表面之下发现蛛丝马迹。但是，发现和修正不干净代码要花去你很长的时间，把你折磨得够呛。
你精心构建代码，发挥洞察力，将它们写得清晰易懂，不容易出错。

作者认为做好的做法是：
寻找一种代码的书写规范，让错误的代码变得更容易被看出。
让代码中的相关信息在显示屏上集中在一起，使你能够当场发现和改正某些种类的错误

作者还批评了异常处理，认为这不是一个好工具

这部分没太理解，作者给出了一些推荐阅读材料 Making Wrong Code Look Wrong 这篇博客最后 More Reading 部分
Raymond Chen’s essay: Cleaner, more elegant, and harder to recognize

Part 6: Starting a Software Company

24 Foreword to Eric Sink on the Business of Software

有趣的小故事，有一项不断成长的生意会让人非常有成就感（~~顺便还吐槽了一波他遇到的垃圾人~~

25 Foreword to Micro-ISV: From Vision to Reality

开头大力吐槽微软高高在上的姿态，语言太幽默，忍不住笑出声

作者对想创业的人给出三条建议：

如果你说不清楚你的软件解决了什么棘手的问题，就不要去开软件公司。
不要独自一人创办公司。
一开始不要抱太高期望。

作者描述创业的乐趣：

总结一下，我所认为的创办软件公司的真正乐趣就是，创造一些东西，自己参与整个过程，悉心培育，不间断地劳作，不断地投入，看着它成长，看着自己一步步的到报偿。这是世界上最带劲的旅程，无论如何，我都不想错过它。

26 Singing High Notes

软件的复制成本为零，如果销售量很大，高价雇佣程序员的成本可以分摊到销量上，单位软件成本并不会显著上升

优秀程序员的生产效率比普通程序员高 5 到 10 倍，那么是否可以用 5 个平庸程序员来代替 1 个优秀程序员呢？
答案是不能，不仅因为布鲁克斯法则（Brooks‘ Law）：向一个已经延误的软件项目增加人手，只会使它更加延误

Brooks 就是《人月神话》（The Mythical Man-Month）的作者
而且平庸的程序员无论工作多长时间，他们做出来的东西也无法像优秀程序员一样好
一流的歌唱演员不管在什么时候，都可以很轻松地唱出高音，而平庸的歌唱演员就是永远做不到这一点

Part 7: Running a Software Company

27 Bionic Office

作者开公司，他是一个真正的程序员，并且按照他的理想布置了适合程序员工作的办公空间，最终成本是人均 700$/月，非常舍得花钱
去 wiki 上看了看公司的后续，疫情期间被收购了，详细情况不太了解，但还是叹息，理想主义公司生存真是太困难了

28 Lessons from Other Hills

将 FogBugz 许可证变为公开源代码的理由

29 Simplicity

简化 并不是 简陋
产品易于理解使用、外观简洁明快，都是加分项
但不能把 简化 理解为 不提供大量功能 或者 只提供一种功能，并把这种功能完美实现

30 Knead It, Rub It

代码重构（refactoring）的原则：

不添加任何新功能
无论何时向源码库提交代码，都要保证程序依然能够完善地运行
制作一些合乎逻辑的变换（logical transformation），几乎都是机械性的，而且能够立刻确定不会改变代码行为

作者认为这样的重构有许多优点：

耗时大大少于一次彻底的重写
没有引入任何新错误
在任何时间，如果有必要，都可以停下来，把程序交出去
工作进度是完全可以预测的
重构所花费的时间可以为之后的新功能开发节省时间

31 The Twelve Best Tips for Running Beta Tests

开放式的 Beta 测试是没用的
要想找到那些能够向你反馈意见的测试者，最好的方法是诉诸他们 言行一致 的心理。你需要让他们自己承诺会向你发送反馈意见，或者更好的方法是，让他们自己申请参加 Beta 测试。
不要妄想一次完整的 Beta 测试的所有步骤能够在少于 8~10 周的时间内完成
不要妄想在测试中发布新的软件版本的频率能快于每两周一次
一次 Beta 测试中计划发布的软件版本不要少于 4 个
如果在测试过程中你为软件添加了一个功能，那么哪怕这个功能非常微小，整个 8 个星期的测试也要回到起点
即使你有一个申请参加 Beta 测试的步骤，最后也只有五分之一的测试者会向你提交反馈意见
我们制定了一条政策，所有向我们提交反馈意见的测试者都将免费获赠一份正版软件，不管反馈意见是正面还是负面
你需要的严肃测试者（即那些会把反馈意见写成 3 页纸发送给你的人）的最小数量大约是 100 人左右
根据第 7 条，即使你有一个申请参加 Beta 测试的步骤，最后也只有五分之一的测试者会向你提交反馈意见。那么，假定你有一个质量控制部门，里面一共有 3 个测试管理人员，这就意味着你必须批准 1500 份参加 Beta 测试的申请表，因为这样才能产生 300 个严肃测试者。
大多数 Beta 测试的参与者只是在第一次拿到这个程序的时候才会去试用一下，然后就丧失了兴趣。你需要错开不同版本的测试对象，将所有 Beta 测试参与者分成四组，每次发布一个新版本的时候，就把一个新的组加入测试，这样就能保证每个版本都有第一次使用这个程序的测试者。
不要混淆 技术 Beta 和 市场 Beta。上面这些都是针对 技术 Beta，它的目标是发现软件中的错误和得到及时的用户反馈意见。

32 Seven Steps to Excellent Customer Service

每件事都有两种做法
一种是简单、快速的解决当前问题
另一种是把探究问题产生的原因，一劳永逸地解决这个问题。长此以往，所有常见的和容易的问题都被解决了，留下来的都是一些非常罕见和奇特的问题。这样可以节省常规性技术支持的成本。
当然，后一种办法对客服人员的要求更高，需要技术支持团队可以与开发团队直接沟通。
建议吹掉灰尘
Raymond Chen 讲过一个小故事。有一次，客户打电话来抱怨键盘失灵，结果不出所料，原因是键盘没插好。但是如果你直接问客户键盘有没有插好，他们会觉得受到了侮辱，怒气冲冲地回答：“它当然插好了！难道我看上去像一个笨蛋吗？”而实际上，他们并没有检查过接口。
“你可以换一种说法，” Raymond Chen 建议改成这样说：“别着急，有时候键盘接口会有灰尘，导致接触不良。你能不能拔掉键盘插头，吹掉上面的灰尘，然后再把它插回去？”
“然后，客户爬到桌子底下，发现自己忘了插好插头（或者把插头插入错误的接口）。他们把灰尘吹掉，插入插头，回复你说：‘嗯，很好，问题解决了，谢谢。’”
很多时候，我们要求客户去检查某样东西，都可以这样表达。不是直接要求他们去检查某个设置，而是告诉他们先改变这个设置，然后再改回去，目的是 “确保这个设置被保存进了软件”。
让客户迷上你
客户遇到问题，你帮他解决了，并且是以漂亮的、超过客户预期的方式解决这个问题后，客户实际上变得比没有问题时还要满意，很容易成为你的重视客户，还会向别人推荐。
承受责备
坦诚地承认自己的错误
学会说软话
和上条一样，承认自己的过失，并解决问题，防止他人对你火冒三丈
学会做木偶
还是和上面类似，对事不对人，不要觉得别人的批评是对自己的人身攻击
贪婪让你一无所获
作者的公司 Fog Creek 的客服从来没有遇到过愤怒的顾客，他们公司的退款政策是 “如果你是用我们的产品，不觉得异常欣喜，我们就不要你的钱”
这样顾客就不会有后顾之忧，大不了退钱。
作者公司设置这样异常慷慨的退款政策，6 年时间中，因为接受顾客退货儿导致的成本只占总成本的 2%。
如果把退款政策制定的很严格和苛刻，反而有可能会惹火一些顾客，损失潜在客源。

附赠建议：为客服人员提供职业发展道路
作者安排了非常称职的人与客户交谈，Fog Creek 的销售人员对软件开发流程有丰富的经验
通过改进软件，他们已经把常见问题都消灭了，技术支持工作实际上变成了处理疑难杂症，需要经常对程序进行调试和除错
作者还为客户服务人员提供一条明确的职业发展道路，公司出钱让他们攻读哥伦比亚大学技术管理的硕士学位
这让作者招聘到有抱负、聪明的技术人才，尽管付出了超额成本，但也创造出了比一般水平多得多的价值

Part 8: Releasing Software

33 Choosing a Release Date

制定软件开发周期的基本规则：

确定发布日期，这个日期可以根据客观情况也可以根据主观情况进行选择
列出软件要实现的功能，然后按照优先顺序排序
每当你落后于预订进程时，就把排在最后的功能砍掉

挑选软件发布日期的规则：

经常发布稍作改进的版本。适合顾客人数较少的项目。
每 12 个月到 18 个月发布一次。适合上架销售的商业软件和桌面应用程序，拥有大型开发团队和成千上万名顾客。
每 3 到 5 年发布一次。常见于超级庞大的软件系统和平台。

不要因为答应过一个顾客而开发某个功能，应该始终面向整个市场开发软件
不要因为某些事情不得不做，你就去做。不得不做不是一个足够好的理由，要想清楚什么是眼下最重要的、必须马上做好的事情

确定软件开发中各种任务的优先顺序的步骤：

召集尽量不同观点/视角的团队：程序员、设计师、客服人员、销售人员、管理人员、文档作者、测试员，甚至包括客户。每个人都提出一些想要实现的功能，最后得到一份包含 50 项重大功能的清单
审查这些功能，每个人进行表决，简单地表示 “赞成” 或是 “反对”，筛选过后，剩下 36 个功能
为每个功能设定一个成本，用 1 到 10 表示，这一步只是区分小型任务、中型任务、大型任务，不需要精确计算实际开发所需的时间
把 36 个功能和它们的成本做成一张菜单，每个人有 50 美元用来点菜。可以买半个功能，也可以同样功能买两个
汇总每个功能的销售额，用 销售额 除以 成本，找出最受欢迎的功能
最后可以根据功能之间的联系做一些调整
优先顺序确定之后，按照清单从上往下进行开发，直到开发阶段结束，没有时间完成的功能就直接舍弃，或是留到下个版本开发

Closing Notes

看一遍，复读一遍，特别是在学习了 Python 和 JavaScript 里函数式编程概念之后，对一些章节理解更加深刻了
不错，有收获

Comments