Feynman famously said: Imagine how much harder physics would be if electrons had feelings.

Getting started shouldn't be an afterthought after you built the product. Getting started is the product!

入门不应该是在构建产品之后才考虑的问题。入门就是产品！

…

Make it possible for users to use your product on their laptop in a couple of minutes, tops.

让用户在几分钟内就能在笔记本电脑上使用您的产品。

产品要让使用者能快速上手，要是需要配置一堆东西，花半天时间，可能不少用户会放弃使用。

Too many programming books and tutorials are like “let’s build a house starting from scratch, brick by brick” when what I want to “here is a functioning house, let’s learn about it by changing something and then seeing what happens”

太多的编程书籍和教程就像“让我们从头开始，一砖一瓦地建造一座房子”，而我想要的是“这里是一座正常运转的房子，让我们通过改变一些东西来了解它，然后看看会发生什么”。

The sad but true part of programming is, the default mode is that you're fixing an error of some sort. This means that users are going to spend the majority of the time with your tool trying to figure out what's not working.

编程的可悲但真实的一面是，默认模式是你在修复某种错误。这意味着用户在使用工具的过程中，大部分时间都在试图找出问题所在。

• Developers getting to success faster are happy developers. They will like your tool. 更快获得成功的开发人员是快乐的开发人员。他们会喜欢你的工具。
• Developers banging their heads against errors are sad developers. They will blame your tool. 在错误面前磕头的开发人员是可悲的开发人员。他们会指责你的工具。

Put code snippets in the exceptions. Emit helpful warnings when users are likely to do something weird. Do what you got to do to make the user succeed.

在异常中加入代码片段。在用户可能做出奇怪举动时发出有用的警告。尽你所能让用户成功。

如果使用你工具的人总是碰到问题，而且也没有足够的反馈告诉用户如何解决问题，用户就会有很多挫败感，从而放弃使用这个工具。

相反，给用户足够的反馈，尽可能地帮助他们顺利地使用你的工具，用户就会快乐地继续使用你的工具。

Every new conceptual thing you have to understand before using the tool makes is a new friction point. If it's 2-3 things, that's fine. But no one is going to bother learning 8 new concepts.

在使用工具之前，你必须了解的每一个新概念东西都是一个新的摩擦点。如果是 2-3 个东西，那还好。但是没有人会去费心学习 8 个新概念。

避免概念过载，降低用户的心智负担。关于心智负担，可以看看 Cognitive Load is what matters。

Somewhat related to the previous point, let's say in your framework you introduce a thing that takes some values and evalutes to a new values. What do you call it? A compute node? A valuator? A frobniscator?

No! You call it a function!

与前一点有些关联的是，假设在你的框架中引入了一个东西，它可以获取一些值并求值到一个新值。你怎么称呼它？计算节点？估值器？估值器？

不！你称之为函数！

If it walks like a duck, and it quacks like a duck, it probably is a duck.

如果它走起路来像鸭子，叫起来也像鸭子，那么它可能就是一只鸭子。

Calling it a function means you latch onto a users pre-existing mental model of what a function does. Which will save you like, 90% of the explanation of how to think about this object.

将其称为函数意味着你抓住了用户关于函数作用的已有心智模型。这将省去 90% 的解释工作，让你知道如何看待这个对象。

Unless defaults apply in 97%+ of the time, and unless magic applies 99% of the time, be careful about introducing it. These are not exact numbers obviously, but my point is, you need to be very very judicious.

除非在 97% 以上的情况下使用默认设置，除非在 99% 的情况下使用特殊方法，否则在引入时一定要小心谨慎。这些显然不是精确的数字，但我想说的是，你需要非常非常谨慎。

I sometimes think the challenge of designing for the 1st time user is similar to making a pop song. The producer will listen to the song a thousand times. But still the 999th time they hear it, they need to imagine what it sounds like to a person that hears it the first time, which seems… super hard.

我有时认为，为第一次使用的用户进行设计所面临的挑战与制作一首流行歌曲类似。制作人会听上千遍这首歌。但在第 999 次听到这首歌时，他们仍需要想象第一次听到这首歌的人听起来是什么感觉，这似乎……超级困难。