同样是赚钱，依靠的东西并不一样。

• 靠体力
  • 比如工地工人；一些技术含量低的，也可以说是靠体力。
• 靠技术
  • 比如程序员，本质上是靠技术，出卖自己的时间赚钱。
• 靠资本
  • 比如投资家，基本是钱生钱的生意。
• 靠品牌
  • 比如公司产品，即便不如竞品，但只要有品牌、存量用户，依然能活得不错。

你，靠什么？

最近在家带娃，能干活的时间不多。而如果等有时间了再考虑做什么、怎么做，就太慢了，毕竟时间太少了。

应该在带娃的时候，就要在脑子里想问题。比如，接下来要做什么，准备怎么做，可能会遇到什么问题，等等。有了这些铺垫，等有时间时，就可以直接上手干活，不至于在想的过程中浪费时间。

Klib 从 Amazon 导入标注，逆向了官方的一些接口。可最近，官方的接口有变化，导致 Klib 导入失败。

今天紧急救火，终于还是解决了。其实还是挺麻烦的：

• 逆向本身有些麻烦，要用抓包工具、看 html/js 等源文件等方式，甚至还要加上猜测与运气的成分，才能跑通。
• 更关键的，这样只能覆盖自己本身的情况。而用户的数据不同，程序流程上可能会进入不同的分支；很可能逆向时并未覆盖这一分支，就会导致失败。

虽说目前算是解决问题了，但明显这样的感觉很不好：要是大年三十出问题了，我总不能不吃年夜饭吧。现在心里大体有更靠谱的方案了，不过需要大块时间来实现。考虑到马上要过年，就很不折腾了，下次出问题时再彻底替换吧。

自己的写的代码，不管好坏，都是自己写的，毕竟熟悉。即使是对于复杂的逻辑，通常是在简单的逻辑上慢慢生长的，所以也算容易理解。

而直接看别人的代码，尤其是复杂的、本身结构不太优的、夹杂着一些自己的不懂的技术的，看起来真是累啊。

现在只能这样尝试：

• 硬着头皮看。看到不会的东西，做个标注。如果已经做的标注实在太多、看不下去了，就回过头来一个个搞定这些标注。
• 对于相同的功能，尝试自己设计，看自己会怎么做。然后对比别人的做法，更容易理解其这样做的目的，发现其中好的、不好的地方。

但依然很累，催眠效果很棒…

首先，用户选择我的产品，就是对我的信任，也有很多的期许。

如果不能好好地服务用户，比如反馈不及时，自然会让用户感觉失望，甚至为自己选择这个产品而感到失落。

而如果能服务好，甚至超出预期，比如快速响应用户的问题，用户的满意度自然会很高。而这样的用户，通常愿意提供帮助，比如出问题时提供详细的步骤、帮助介绍给周围需要的朋友，等等。

且不说衣食父母，尊重用户，不仅应该，而且很值得。用户的反向尊重，通常会超出预期。