我如何使用 Apple Notes 做笔记
via Randy's Blog
via Randy's Blog
Lutaonan
我如何使用 Apple Notes 做笔记 | Randy's Blog
About life, technology and reading
新 MacBook 的设置和软件
趁着国补，把手头用了 5 年的 MacBook Air M1 换成了 MacBook Pro 14 寸 M4. 顺便手动重新配置新电脑，在此记录一下每次设置新电脑时我会做的一些设置和必装的软件。
设置
把点按切换成轻点：
我不喜欢用触摸板点按拖动来移动窗口，觉得有点费力，所以我会调整为三指拖移。旧版本的 OS X 可以直接在系统设置中调整，新版本的 macOS 竟然把它归类到辅助功能里了：
把 Control 键和 Caps Lock 键互换。因为我需要频繁使用 Control 键，Caps Lock 的位置是最合适的，这也是 HHKB 的默认布局：
取消 Spotlight 的所有索引，因为我用 Raycast, Spotlight 的索引会浪费计算资源:
软件
● Microsoft Edge: 用了很多年的主力浏览器
● 清歌五笔输入法: 最好用的五笔输入法
● Raycast: 不必多说
● Cursor: 目前主力 IDE, 也是 Cursor 长期的订阅用户
● CleanShotX: 最好用的截图软件，除了截图还有很多好用的小功能（比如 OCR, 录屏）
● 1Password: 密码管理
● Warp: 主力 Terminal Emulator, 已经离不开通过 AI 写复杂的命令
● iStat Menus: 在 Menu bar 显示系统信息，我用来实时看到网络传输速度和内存使用情况
via Randy's Blog
Invalid media:
image
image
image
image
趁着国补，把手头用了 5 年的 MacBook Air M1 换成了 MacBook Pro 14 寸 M4. 顺便手动重新配置新电脑，在此记录一下每次设置新电脑时我会做的一些设置和必装的软件。
设置
把点按切换成轻点：
我不喜欢用触摸板点按拖动来移动窗口，觉得有点费力，所以我会调整为三指拖移。旧版本的 OS X 可以直接在系统设置中调整，新版本的 macOS 竟然把它归类到辅助功能里了：
把 Control 键和 Caps Lock 键互换。因为我需要频繁使用 Control 键，Caps Lock 的位置是最合适的，这也是 HHKB 的默认布局：
取消 Spotlight 的所有索引，因为我用 Raycast, Spotlight 的索引会浪费计算资源:
软件
● Microsoft Edge: 用了很多年的主力浏览器
● 清歌五笔输入法: 最好用的五笔输入法
● Raycast: 不必多说
● Cursor: 目前主力 IDE, 也是 Cursor 长期的订阅用户
● CleanShotX: 最好用的截图软件，除了截图还有很多好用的小功能（比如 OCR, 录屏）
● 1Password: 密码管理
● Warp: 主力 Terminal Emulator, 已经离不开通过 AI 写复杂的命令
● iStat Menus: 在 Menu bar 显示系统信息，我用来实时看到网络传输速度和内存使用情况
via Randy's Blog
Invalid media:
image
image
image
image
「代码艺术家」不会被 AI 取代
最近大量地使用 Cursor 替代了 VS Code, 开始习惯直接在编辑器里告诉 AI 我的需求，让它来代替我写出代码段。
请注意，我用了「代码段」这个词，而不是「代码」，因为我想做一个区分 —— 按照我目前的经验来看，生成式 AI 非常擅长生成一段内聚的代码，而不是一整个应用程序。
在没有 AI 生成代码前，我写代码也是这样的一个流程：
1. 思考整个应用的架构、模块
2. 选择适合的技术栈
3. 开始写代码，设计目录结构、抽象
4. 真正开始实现实现
AI 也许能为第 1 和第 2 点提出建议，但我目前不需要。第 3 点我认为对于稍微复杂一点的生产级应用， AI 还做不到把这一块也做到。可能很多人看到现在 Claude 直接能写出一个全功能的 Todo List 就惊叹 AI 要取代程序员了，我觉得真正写过一个完整的给用户使用的「应用」的朋友对此都会很淡定。
对于我来说，只有在第 4 步（实现） 的阶段才真正能杠杆 AI 的能力。我会尽可能地描述清楚我的需求，让 AI 能理解我要做的任务，让它来生成满足我的抽象的代码，或修改现有的代码。
这里我提到的描述清楚我的需求是用 AI 生成代码中最重要的一点。所谓的「需求」不仅仅是描述这个函数需要做什么事情，还需要包含这个函数应该接收什么参数，返回的是什么数据结构。
例如，我在做的一个应用，其中我需要一个上传文件到 S3 的函数。在这个需求中，如果我单纯告诉 AI它要做什么，那我很有可能得到一个可以实现功能但不适合我调用的函数，因为 AI 没有上下文去确定我可以传哪些参数给它。
![cursor 截图]../../../images/telegram-cloud-photo-size-5-6168067452672523878-y.jpg
在深度和 AI 「结对编程」后，我对于「AI 是否能取代程序员」这个问题有了更深刻的思考。
有了 AI, 我现在写代码花的精力主要是在「设计」上，例如思考这个应用的交互设计，例如整个应用的架构设计。所谓的架构设计，一部分的工作是决定这个系统里要有什么模块，一部分的工作是决定这些模块如何串联在一起。而这些设计工作恰恰是我写代码的时候最喜欢做的，对我来说，写代码就应该是一个设计的过程，设计出优雅、易用、易扩展的接口是一件很有成就感的事。这也是我当初看 Head First Design Patter 这本书时的感受。 如果写软件变成了一个只需要花精力在设计而不是实现上的过程，那么写软件的人就是「代码艺术家」了。我觉得「代码艺术家」是不会被 AI 取代的，因为设计的起点和终点都是人类，AI 可以给你 100 个设计上的答案，但只有人类最终能感知到现实和当下的环境和信息，创造出能触动另一群人类的产品。
如果你从现在开始，开始把 AI 当作是你的员工，就像某一天你突然只需要 $20 一个月就能招无数多愿意帮你打工的人，你很快就会发现，你最终会面临两种局面：
局面1：你将手足无措，你突然发现如果你不是实现函数的那个人，你就不知道你应该做什么了。从前你沾沾自喜的手写快排，手写红黑树突然变得一文不值，无处施展。
局面2：你将如虎添翼，你突然发现你曾经有很多想法没有精力和时间去实现，现在突然有这么多廉价劳动力将不厌其烦地帮你写代码，而你要做的只是设计好整个系统的结构，把具体实现外包给 AI. 然后把产品推出市场，去碰壁，去失败，去成功。显然，AI 不能替代你去碰壁，去失败，去成功，但真正让你变得强大的不是你手写快排有多烂熟于心，而是去碰壁之后学习到的东西。
AI 不会替代「代码艺术家」，因为 AI 是「代码艺术家」的喷射机。
读到这里，可能有人要说，Randy, 你飘了，你开始技术虚无主义了。在这里我要申明，这篇文章我是写给有一定经验的程序员看的。对于没有什么经验的程序员，多写点代码总是好的（至少目前来看）。AI 能力的上限是由用的人的上限决定的。无论是任何行业，充分掌握领域知识后配合 AI 才是最好的做法。
就像下面这个例子，我只要说一句 add tanstack query provider 就能让 AI 帮我把 @tanstack/query 加到我的程序里。我自己会写，但我自己写可能要花一两分钟，但 AI 一下子就好了。
![cursor 截图]../../../images/telegram-cloud-photo-size-5-6165685253356765301-y.jpg
但如果你没有任何代码经验，你连 tanstack query 是什么都不知道，也不知道要放在程序的哪个地方，那用 AI 还是有点困难。
写下这篇文章是因为最近用 Cursor 有感，加上刚好看到 Daniel Nguyen 发了一篇 Software is Art, 有感而发，不吐不快。在此粗浅翻译（非 GPT），作为结尾：
via Randy's Blog
最近大量地使用 Cursor 替代了 VS Code, 开始习惯直接在编辑器里告诉 AI 我的需求，让它来代替我写出代码段。
请注意，我用了「代码段」这个词，而不是「代码」，因为我想做一个区分 —— 按照我目前的经验来看，生成式 AI 非常擅长生成一段内聚的代码，而不是一整个应用程序。
在没有 AI 生成代码前，我写代码也是这样的一个流程：
1. 思考整个应用的架构、模块
2. 选择适合的技术栈
3. 开始写代码，设计目录结构、抽象
4. 真正开始实现实现
AI 也许能为第 1 和第 2 点提出建议，但我目前不需要。第 3 点我认为对于稍微复杂一点的生产级应用， AI 还做不到把这一块也做到。可能很多人看到现在 Claude 直接能写出一个全功能的 Todo List 就惊叹 AI 要取代程序员了，我觉得真正写过一个完整的给用户使用的「应用」的朋友对此都会很淡定。
对于我来说，只有在第 4 步（实现） 的阶段才真正能杠杆 AI 的能力。我会尽可能地描述清楚我的需求，让 AI 能理解我要做的任务，让它来生成满足我的抽象的代码，或修改现有的代码。
这里我提到的描述清楚我的需求是用 AI 生成代码中最重要的一点。所谓的「需求」不仅仅是描述这个函数需要做什么事情，还需要包含这个函数应该接收什么参数，返回的是什么数据结构。
例如，我在做的一个应用，其中我需要一个上传文件到 S3 的函数。在这个需求中，如果我单纯告诉 AI它要做什么，那我很有可能得到一个可以实现功能但不适合我调用的函数，因为 AI 没有上下文去确定我可以传哪些参数给它。
![cursor 截图]../../../images/telegram-cloud-photo-size-5-6168067452672523878-y.jpg
在深度和 AI 「结对编程」后，我对于「AI 是否能取代程序员」这个问题有了更深刻的思考。
有了 AI, 我现在写代码花的精力主要是在「设计」上，例如思考这个应用的交互设计，例如整个应用的架构设计。所谓的架构设计，一部分的工作是决定这个系统里要有什么模块，一部分的工作是决定这些模块如何串联在一起。而这些设计工作恰恰是我写代码的时候最喜欢做的，对我来说，写代码就应该是一个设计的过程，设计出优雅、易用、易扩展的接口是一件很有成就感的事。这也是我当初看 Head First Design Patter 这本书时的感受。 如果写软件变成了一个只需要花精力在设计而不是实现上的过程，那么写软件的人就是「代码艺术家」了。我觉得「代码艺术家」是不会被 AI 取代的，因为设计的起点和终点都是人类，AI 可以给你 100 个设计上的答案，但只有人类最终能感知到现实和当下的环境和信息，创造出能触动另一群人类的产品。
如果你从现在开始，开始把 AI 当作是你的员工，就像某一天你突然只需要 $20 一个月就能招无数多愿意帮你打工的人，你很快就会发现，你最终会面临两种局面：
局面1：你将手足无措，你突然发现如果你不是实现函数的那个人，你就不知道你应该做什么了。从前你沾沾自喜的手写快排，手写红黑树突然变得一文不值，无处施展。
局面2：你将如虎添翼，你突然发现你曾经有很多想法没有精力和时间去实现，现在突然有这么多廉价劳动力将不厌其烦地帮你写代码，而你要做的只是设计好整个系统的结构，把具体实现外包给 AI. 然后把产品推出市场，去碰壁，去失败，去成功。显然，AI 不能替代你去碰壁，去失败，去成功，但真正让你变得强大的不是你手写快排有多烂熟于心，而是去碰壁之后学习到的东西。
AI 不会替代「代码艺术家」，因为 AI 是「代码艺术家」的喷射机。
读到这里，可能有人要说，Randy, 你飘了，你开始技术虚无主义了。在这里我要申明，这篇文章我是写给有一定经验的程序员看的。对于没有什么经验的程序员，多写点代码总是好的（至少目前来看）。AI 能力的上限是由用的人的上限决定的。无论是任何行业，充分掌握领域知识后配合 AI 才是最好的做法。
就像下面这个例子，我只要说一句 add tanstack query provider 就能让 AI 帮我把 @tanstack/query 加到我的程序里。我自己会写，但我自己写可能要花一两分钟，但 AI 一下子就好了。
![cursor 截图]../../../images/telegram-cloud-photo-size-5-6165685253356765301-y.jpg
但如果你没有任何代码经验，你连 tanstack query 是什么都不知道，也不知道要放在程序的哪个地方，那用 AI 还是有点困难。
写下这篇文章是因为最近用 Cursor 有感，加上刚好看到 Daniel Nguyen 发了一篇 Software is Art, 有感而发，不吐不快。在此粗浅翻译（非 GPT），作为结尾：
I realize the reason I like building is not just because I’m a builder.
我意识到我一直喜欢创造点东西的原因不只是因为我就是个创造者.
It’s because software products are how I express my creativity.
而是因为写软件产品是我表达我的创意的一种方式
It’s like a poem to a poet, a song to a songwriter, a painting to a painter…
就像诗人的诗，歌手的歌，画家的画
Software is my art form, my medium of expression.
软件是属于我的一种艺术形式，是我表达（创造力）的媒介。
via Randy's Blog
不上班的第一年
2023 年的 5 月，我离开了微软，开始了自己做产品的旅程。到现在刚好满了一年，这一年发生了不少事情，有些在 2023 年终总结里提到过，这一篇我想更详细地列出在这一年我具体做了什么、对自由职业的思考、对做产品的一些思考等等。
首先是我的产出，这一年我的产出主要是两个产品、一个播客。
两个产品
Notepal
离职后第一个认真做的产品是 Notepal, 这是一个用于把微信读书笔记同步到各个笔记应用的插件。我在这篇文章详细写过这个产品的起源和在做这个产品的时候的一些思考。我在做这个产品的时候完全没有想到，这个只卖 50 块的插件，在这一年帮我付了我一整年的房租。
EpubKit
EpubKit 是另外一个我投入比较多的产品。这是一个把网页转成 ePub 电子书的工具。正式上线不到一个月，收获了几十个付费用户。
一个播客
刚好今年的 5 月份也是我和 GeekPlux 一起做的播客节目《代码之外》 的一周年。起初我们只是玩票性地做闲聊节目，后来因为有了听众来信的栏目，我们慢慢会讲更多职业发展方向的主题，这些主题意外地无形中对很多听众有不少的帮助。后来还邀请我刚工作就很欣赏的前辈勾股作为来信栏目的常驻嘉宾，为节目带来了很多很好的观点。今年在参加一些线下活动时，有些听众会跟我说从节目中得到了启发。从统计数字上看，我们好像的确是做了一件影响力不算小的事：
● 小宇宙订阅数 6000+, 总播放量 11万+
● Bilibili 粉丝 6000+，总播放量 13万+
● YouTube 订阅数 2500+, 总播放量 3万+
在这一年，我对于做产品和生活都有了很多思考。对于不上班这件事，有人羡慕，有人好奇，刚好在这篇总结里，我想跟大家分享不上班的好处和缺点。
不上班的好处
时间自由
不上班的好处对我来说最明显的是时间自由。我是一个喜欢晚睡晚起的人，所以对我来说，准时上班是一件很难的事。不上班可以让我睡到自然醒，有充足的睡眠时间。
认识不同的人
上班的时候基本只能认识职场环境里面的同事朋友，或者在网络上交流的朋友。但是在自己做产品后，我开始认识一些同样是在做产品的朋友，和这些朋友可以聊得更深入。这些人往往对很多事情都有自己独特的思考。我从他们身上学习到非常多。我经常觉得如果我只是和以前一样在公司上班，业余写写博客和开源，我可能很难和这些朋友有共同话题，最多也只是互相点赞之交。
赤裸地直面市场
不上班后只能完全依靠自己赚钱，这代表我需要很赤裸地直面市场。
第一层赤裸，指的是脱离公司，作为一个个体，我可以给消费者提供什么他们认为值得为我付费的价值？
第二层赤裸，指的是一个产品如果脱离大公司本来就有的入口红利，我靠什么给我的产品带来自然流量？
这些都是很难的问题，但一旦开始学习，收获都是巨大的，而且都是属于自己的。在公司里最可怕的地方在于，我们很容易把公司给的平台误以为是自己的能力，很容易把流量看成是理所当然会有的。
也正因为如此，在这个过程中，我可以学习到很多以前不会主动学习的技能。
学习到更多技能
自己做产品的时候，没有公司平台给的入口，首先需要学习的就是如何做 marketing. 也是只有在自己做产品的时候，才会发现要别人发现你的产品是一件多么难的事。回想以前在阿里做业务，我们写一个营销活动页面，只要把入口放到某个栏位，基本不需要担心没有流量。
为了获客，我学会了研究 SEO, 学会了怎么做小红书，读了很多关于 marketing 的书。这让我学习了很多技术之外的知识，我觉得这些知识是终生受用的，而且它们不仅可以在互联网行业受用。
不上班的缺点
没有固定收入
不上班最大的缺点就是没有固定收入，这是很现实的问题。坦率地说，我以前买东西基本不看价格，只要觉得有价值，我就会买。没有固定收入之后，我买东西变得更加谨慎了。比如最近我很想买一台 Studio Display, 换作以前，无需多想，直接下单。但是现在，我会想我要卖多少份软件才能 cover 这台显示器，想想还是算了。
有时候我的朋友说羡慕我不用上班，我就跟他们说我这一年的收入还没有你们一个月赚得多，他们心理也就平衡了🤣。
孤独
可能有些人就是喜欢不用和别人交流，但对我来说，我是喜欢社交的，我在适当的社交中可以获取能量。不上班的时候，大部份的时间都是在家里写代码，看书，在网上和朋友聊天。有时候一整天都不需要开口说一句话。到后来我有点受不了，开始到外面的咖啡厅办公，只要能见到旁边有活人，就能有所缓解这种孤独感。
不确定性
上班有上班的不确定性要面对，不上班也有不上班的不确定性要面对。你无法确定这种生活可以维持多久，你的产品是否能卖得出去，就算卖得出去，它是否能养活自己，这些都是要面对的问题。
这些就是我体会到的不上班的一些优缺点，接下来，我想讲讲这一年在做产品的过程中我的一些思考和感受。
思考和感受
独立开发？
「独立开发」这个词在这一年非常火，用来标签像我这样自己做产品的开发者。其实我一直不称自己为「独立开发者」，因为我根本不想「独立」开发。我想做 scope 更大的事情，只是现在还没有条件。如果可以，我更愿意和两三个志同道合的人一起做产品。就像 61 的谜底科技，像少楠的 flomo.
而且自己做产品这一年，让我深刻地意识到，真正要做「独立」开发是很难的，因为没有人能擅长所有技能。
没有人擅长所有技能
曾经我觉得只要我愿意去学，我就能做好。比如设计。我很注重产品的 UI/UX 设计，但我一直没有经过认真的设计学习和训练。我读了些关于 UI/UX 的书，以为就可以成为一个设计还不错的程序员。后来发现我错了，理论和实践之间原来有一条很大的鸿沟。我虽然知道很多设计和用户体验的理论，但是一旦真正动手做页面，这些理论完全无法转换成实际的设计。
这是因为设计和写代码一样，是需要长期积累的。优秀的设计师可能有审美天赋，但他们一定也是每天都观察大量的设计，在自己的脑中内化了很多设计的模式（我不知道有没有专业的术语来形容），这些积累使他们可以面对一个新的需求的时候，根据自己内化的东西产生新的设计，这是我这种只读过一些理论的人无法做到的。正如会写代码的设计师，可能可以写一点能跑的代码，但缺乏多年的代码实践经验，是不可能像真正的专业程序员一样根据经验做好技术选型和想应该用什么设计模式（design pattern）的。
不过，我还是学会了在看到一些设计的时候，比以往更深入地去思考这个设计，这些元素为什么会这么摆放，颜色是怎么运用的，等等。
人的时间和精力是有限的
Notepal 和 EpubKit 同时做，让我更能体会到人的时间和精力是有限的。把时间放在一个产品 4 小时，那么另外一个产品投入的时间就永远少了 4 小时。而且上下文切换（context switch）是非常耗精力的。比如你正在修产品 A 的 bug, 这时用户报了产品 B 的 bug, 要从产品 A 跳转到产品 B 的开发，是很难一下子切换过来的。
所以不是自己一个人做产品就不需要项目管理，还是得学会充当自己的 manager 管理自己。给项目列好 roadmap, 排好需求优先级。
关于这个问题我还专门请教了图拉鼎，他告诉我要把自己当成不同的角色来用，比如规定上午作为客服，专门处理用户反馈，下午是程序员，专注写代码。这个方法也让我很受用。
自己做产品，同时要充当开发、marketing、客服、产品设计，我觉得这是「独立」开发的最大挑战。
学会专注
开发完 Notepal 后，我曾经陷入了很长时间的 burnout. 眼下赚的钱也不多，但又不知道应该做什么。期间有一些零星的 idea, 开发完后也不了了之。后来开发了第一版 EpubKit, 有了一些用户，之后又 burnout 了，因为开始觉得它做得不好，也很小众，渐渐又想放弃，想做点别的试试。
后来一些朋友「批评」我说我不够专注，我也开始反思，其实自己做的东西不算很糟糕，只是自己太着急，没有把它们都做得极致就失去耐性。经过反思，我决定好好打磨自己现有的产品，才有了现在这一版自己比较满意的 EpubKit.
乔布斯说专注不是指只做最好的，而是对其它也很好的东西 say no.
另外，缺乏专注很有可能会消耗用户对你的信任。
警惕「快速试错」
「快速试错」、「快速验证想法」是很多人做产品的信条，我相信快速验证想法是重要的，但是更重要的是交给用户的这个产品不应该是一个半成品，它最好是一个 Finished software. 也就是说，即使你不再维护这个产品，它还依旧是个可用的软件。
我曾经也「快速试错」，发布了一些产品，最终不再维护，甚至还有几个用户付费了。我对这种「试错」是愧疚的，因为这很有可能伤害支持你的用户。因此我现在反而发布新产品会更加谨慎，要把用户的感受放在第一位。
这篇文章很好地表达了这个观点。
总结
以上就是不上班的一年我对自己的一些思考的总结，希望对读到的朋友有帮助。这一年我其实算是比较幸运的，虽然收入微薄，但做产品也算是能卖出去，能解决很多人的需求。但同时我还是处于迷茫的阶段，认为自己做的产品还是小打小闹，scope 太小。我还是希望将来能做出满足更大众需求的产品，覆盖面能更广。
我的这些观点不一定对，但也能让读者感受到一个程序员脱离公司的其中一种可能性。
via Randy's Blog
Invalid media:
image
image
2023 年的 5 月，我离开了微软，开始了自己做产品的旅程。到现在刚好满了一年，这一年发生了不少事情，有些在 2023 年终总结里提到过，这一篇我想更详细地列出在这一年我具体做了什么、对自由职业的思考、对做产品的一些思考等等。
首先是我的产出，这一年我的产出主要是两个产品、一个播客。
两个产品
Notepal
离职后第一个认真做的产品是 Notepal, 这是一个用于把微信读书笔记同步到各个笔记应用的插件。我在这篇文章详细写过这个产品的起源和在做这个产品的时候的一些思考。我在做这个产品的时候完全没有想到，这个只卖 50 块的插件，在这一年帮我付了我一整年的房租。
EpubKit
EpubKit 是另外一个我投入比较多的产品。这是一个把网页转成 ePub 电子书的工具。正式上线不到一个月，收获了几十个付费用户。
一个播客
刚好今年的 5 月份也是我和 GeekPlux 一起做的播客节目《代码之外》 的一周年。起初我们只是玩票性地做闲聊节目，后来因为有了听众来信的栏目，我们慢慢会讲更多职业发展方向的主题，这些主题意外地无形中对很多听众有不少的帮助。后来还邀请我刚工作就很欣赏的前辈勾股作为来信栏目的常驻嘉宾，为节目带来了很多很好的观点。今年在参加一些线下活动时，有些听众会跟我说从节目中得到了启发。从统计数字上看，我们好像的确是做了一件影响力不算小的事：
● 小宇宙订阅数 6000+, 总播放量 11万+
● Bilibili 粉丝 6000+，总播放量 13万+
● YouTube 订阅数 2500+, 总播放量 3万+
在这一年，我对于做产品和生活都有了很多思考。对于不上班这件事，有人羡慕，有人好奇，刚好在这篇总结里，我想跟大家分享不上班的好处和缺点。
不上班的好处
时间自由
不上班的好处对我来说最明显的是时间自由。我是一个喜欢晚睡晚起的人，所以对我来说，准时上班是一件很难的事。不上班可以让我睡到自然醒，有充足的睡眠时间。
认识不同的人
上班的时候基本只能认识职场环境里面的同事朋友，或者在网络上交流的朋友。但是在自己做产品后，我开始认识一些同样是在做产品的朋友，和这些朋友可以聊得更深入。这些人往往对很多事情都有自己独特的思考。我从他们身上学习到非常多。我经常觉得如果我只是和以前一样在公司上班，业余写写博客和开源，我可能很难和这些朋友有共同话题，最多也只是互相点赞之交。
赤裸地直面市场
不上班后只能完全依靠自己赚钱，这代表我需要很赤裸地直面市场。
第一层赤裸，指的是脱离公司，作为一个个体，我可以给消费者提供什么他们认为值得为我付费的价值？
第二层赤裸，指的是一个产品如果脱离大公司本来就有的入口红利，我靠什么给我的产品带来自然流量？
这些都是很难的问题，但一旦开始学习，收获都是巨大的，而且都是属于自己的。在公司里最可怕的地方在于，我们很容易把公司给的平台误以为是自己的能力，很容易把流量看成是理所当然会有的。
也正因为如此，在这个过程中，我可以学习到很多以前不会主动学习的技能。
学习到更多技能
自己做产品的时候，没有公司平台给的入口，首先需要学习的就是如何做 marketing. 也是只有在自己做产品的时候，才会发现要别人发现你的产品是一件多么难的事。回想以前在阿里做业务，我们写一个营销活动页面，只要把入口放到某个栏位，基本不需要担心没有流量。
为了获客，我学会了研究 SEO, 学会了怎么做小红书，读了很多关于 marketing 的书。这让我学习了很多技术之外的知识，我觉得这些知识是终生受用的，而且它们不仅可以在互联网行业受用。
不上班的缺点
没有固定收入
不上班最大的缺点就是没有固定收入，这是很现实的问题。坦率地说，我以前买东西基本不看价格，只要觉得有价值，我就会买。没有固定收入之后，我买东西变得更加谨慎了。比如最近我很想买一台 Studio Display, 换作以前，无需多想，直接下单。但是现在，我会想我要卖多少份软件才能 cover 这台显示器，想想还是算了。
有时候我的朋友说羡慕我不用上班，我就跟他们说我这一年的收入还没有你们一个月赚得多，他们心理也就平衡了🤣。
孤独
可能有些人就是喜欢不用和别人交流，但对我来说，我是喜欢社交的，我在适当的社交中可以获取能量。不上班的时候，大部份的时间都是在家里写代码，看书，在网上和朋友聊天。有时候一整天都不需要开口说一句话。到后来我有点受不了，开始到外面的咖啡厅办公，只要能见到旁边有活人，就能有所缓解这种孤独感。
不确定性
上班有上班的不确定性要面对，不上班也有不上班的不确定性要面对。你无法确定这种生活可以维持多久，你的产品是否能卖得出去，就算卖得出去，它是否能养活自己，这些都是要面对的问题。
这些就是我体会到的不上班的一些优缺点，接下来，我想讲讲这一年在做产品的过程中我的一些思考和感受。
思考和感受
独立开发？
「独立开发」这个词在这一年非常火，用来标签像我这样自己做产品的开发者。其实我一直不称自己为「独立开发者」，因为我根本不想「独立」开发。我想做 scope 更大的事情，只是现在还没有条件。如果可以，我更愿意和两三个志同道合的人一起做产品。就像 61 的谜底科技，像少楠的 flomo.
而且自己做产品这一年，让我深刻地意识到，真正要做「独立」开发是很难的，因为没有人能擅长所有技能。
没有人擅长所有技能
曾经我觉得只要我愿意去学，我就能做好。比如设计。我很注重产品的 UI/UX 设计，但我一直没有经过认真的设计学习和训练。我读了些关于 UI/UX 的书，以为就可以成为一个设计还不错的程序员。后来发现我错了，理论和实践之间原来有一条很大的鸿沟。我虽然知道很多设计和用户体验的理论，但是一旦真正动手做页面，这些理论完全无法转换成实际的设计。
这是因为设计和写代码一样，是需要长期积累的。优秀的设计师可能有审美天赋，但他们一定也是每天都观察大量的设计，在自己的脑中内化了很多设计的模式（我不知道有没有专业的术语来形容），这些积累使他们可以面对一个新的需求的时候，根据自己内化的东西产生新的设计，这是我这种只读过一些理论的人无法做到的。正如会写代码的设计师，可能可以写一点能跑的代码，但缺乏多年的代码实践经验，是不可能像真正的专业程序员一样根据经验做好技术选型和想应该用什么设计模式（design pattern）的。
不过，我还是学会了在看到一些设计的时候，比以往更深入地去思考这个设计，这些元素为什么会这么摆放，颜色是怎么运用的，等等。
人的时间和精力是有限的
Notepal 和 EpubKit 同时做，让我更能体会到人的时间和精力是有限的。把时间放在一个产品 4 小时，那么另外一个产品投入的时间就永远少了 4 小时。而且上下文切换（context switch）是非常耗精力的。比如你正在修产品 A 的 bug, 这时用户报了产品 B 的 bug, 要从产品 A 跳转到产品 B 的开发，是很难一下子切换过来的。
所以不是自己一个人做产品就不需要项目管理，还是得学会充当自己的 manager 管理自己。给项目列好 roadmap, 排好需求优先级。
关于这个问题我还专门请教了图拉鼎，他告诉我要把自己当成不同的角色来用，比如规定上午作为客服，专门处理用户反馈，下午是程序员，专注写代码。这个方法也让我很受用。
自己做产品，同时要充当开发、marketing、客服、产品设计，我觉得这是「独立」开发的最大挑战。
学会专注
开发完 Notepal 后，我曾经陷入了很长时间的 burnout. 眼下赚的钱也不多，但又不知道应该做什么。期间有一些零星的 idea, 开发完后也不了了之。后来开发了第一版 EpubKit, 有了一些用户，之后又 burnout 了，因为开始觉得它做得不好，也很小众，渐渐又想放弃，想做点别的试试。
后来一些朋友「批评」我说我不够专注，我也开始反思，其实自己做的东西不算很糟糕，只是自己太着急，没有把它们都做得极致就失去耐性。经过反思，我决定好好打磨自己现有的产品，才有了现在这一版自己比较满意的 EpubKit.
乔布斯说专注不是指只做最好的，而是对其它也很好的东西 say no.
另外，缺乏专注很有可能会消耗用户对你的信任。
警惕「快速试错」
「快速试错」、「快速验证想法」是很多人做产品的信条，我相信快速验证想法是重要的，但是更重要的是交给用户的这个产品不应该是一个半成品，它最好是一个 Finished software. 也就是说，即使你不再维护这个产品，它还依旧是个可用的软件。
我曾经也「快速试错」，发布了一些产品，最终不再维护，甚至还有几个用户付费了。我对这种「试错」是愧疚的，因为这很有可能伤害支持你的用户。因此我现在反而发布新产品会更加谨慎，要把用户的感受放在第一位。
这篇文章很好地表达了这个观点。
总结
以上就是不上班的一年我对自己的一些思考的总结，希望对读到的朋友有帮助。这一年我其实算是比较幸运的，虽然收入微薄，但做产品也算是能卖出去，能解决很多人的需求。但同时我还是处于迷茫的阶段，认为自己做的产品还是小打小闹，scope 太小。我还是希望将来能做出满足更大众需求的产品，覆盖面能更广。
我的这些观点不一定对，但也能让读者感受到一个程序员脱离公司的其中一种可能性。
via Randy's Blog
Invalid media:
image
image
读《岩田先生：任天堂传奇社长如是说》
虽然我有 Switch 游戏机, 但我不是游戏的发烧友，对任天堂及其社长岩田聪更不甚了解。前些天听《半拿铁》的《任天堂往事》系列，对任天堂的发展有了一些了解，也听闻岩田聪同时是一个非常出色的程序员，所以开始对岩田聪产生了一些兴趣，于是找到了这本收集了岩田聪说过的话的书，希望能一睹这位天才程序员对管理企业和写程序有哪些独特的见解。
这本书不长，读完后我对岩田聪确实有了更多了解。首先是从他身上学到了一些管理企业的方法。
岩田聪的管理风格非常务实和「接地气」，他讲到他喜欢和员工一对一面谈：
岩田聪还对公司的会议规定必须有一位「会议统筹」：
从岩田聪的谈话中，我感觉岩田聪是一个非常能够洞悉到他人内心感受的人，所以在推进项目的时候，也会非常照顾同事的感受：
如果你本身是一个玩家，可能会对这本书有更深刻的理解。
最后，用岩田先生的话结束这篇读后感：
via Randy's Blog
Invalid media: image
虽然我有 Switch 游戏机, 但我不是游戏的发烧友，对任天堂及其社长岩田聪更不甚了解。前些天听《半拿铁》的《任天堂往事》系列，对任天堂的发展有了一些了解，也听闻岩田聪同时是一个非常出色的程序员，所以开始对岩田聪产生了一些兴趣，于是找到了这本收集了岩田聪说过的话的书，希望能一睹这位天才程序员对管理企业和写程序有哪些独特的见解。
这本书不长，读完后我对岩田聪确实有了更多了解。首先是从他身上学到了一些管理企业的方法。
岩田聪的管理风格非常务实和「接地气」，他讲到他喜欢和员工一对一面谈：
我在与全体员工谈话的过程中，发现了许多“经过面谈才头一回意识到的事情”。就算对方是一向保持着沟通的人，也有在一对一的场合才讲得出口的话。这样说或许不太恰当，但我重新认识到：“假如不制造推心置腹的机会，人是不会敞开心扉的。”在书的最后有宫本茂和糸井重里谈岩田先生的追忆文章，其中糸井重里回忆说：
虽然是第一次见面，但他的话语让人觉得值得信赖。岩田先生曾回忆说：“第一次见面时我也相当紧张。”但我一点也没看出来。“在已有基础上修改，还是从头做起？”这句话单从字面上看会让人觉得不够谦逊，但岩田先生完全没有居高临下的姿态，而是传递出十分看重对方自由选择的权利的感觉。怎么说呢，原本是我们请他来帮忙，但在技术问题之外，岩田先生工作方式的魅力也令我们深受感触，见面次数越多就越发信赖他。结合我从前被管理的感受来看，这让我意识到，管理者能给被管理者足够的信任感是非常重要的，而信任感可以来自于谦逊和务实。
岩田聪还对公司的会议规定必须有一位「会议统筹」：
所谓“会议统筹”，就是让会议良性运转的人。如果会议中缺少创意，就负责添加创意；如果创意太多，导致过于发散，就负责归纳总结。简言之，就是会议的指挥。无论什么会议，都必须有一个决心“要在会议上得出答案”的统筹者。我们在厂里工作过的都知道，很多时候会参加一些没有结论的无用会议，如果每次会议都能指派一个这样的「会议统筹」，相信大家的效率会提高很多。
从岩田聪的谈话中，我感觉岩田聪是一个非常能够洞悉到他人内心感受的人，所以在推进项目的时候，也会非常照顾同事的感受：
世界上许多改革都是运用否定现状的逻辑推行，但这样的做法会让很多人陷入不愉快。因为当下的现状正是许多人的心血、诚意、热情构成的。如果现状由不诚实的东西构成，去否定也无妨，但由诚实的产出构建的现状，不应该被否定。也许正是这样的性格，才能让岩田聪清楚洞悉玩家的感受，从而做出改变世界的游戏。同时，也是因为他是真正有「给别人带来快乐」的强大 passion:
岩田先生发自内心地喜欢看到大家的笑容。他也将这个目标列入任天堂的经营理念。的确，他是一个希望给世界创造更多快乐的人。并且，他是一个为了实现这个目标不惜舍身奉献的人。他喜欢帮助他人，喜欢钻研各种事物，也喜欢为此而沟通交流的过程。所以说，每周一与宫本先生一起吃午饭的时间，凝聚着岩田先生所喜爱的一切。因为他们一起讨论着游戏创意，说着“我懂了”，试图给自己与玩家都带来笑容。我一直觉得，能成大事的人，都是那些内心有一种很强大的 passion 的人。我虽然不是资深玩家，很难从游戏中感觉到快乐，但从岩田先生的谈话中，我还是为他的这种 passion 所感动。
如果你本身是一个玩家，可能会对这本书有更深刻的理解。
最后，用岩田先生的话结束这篇读后感：
在我的名片上，我是一名社长。在我的头脑中，我是一名游戏开发者。但在我心里，我是一个玩家。
On my business card,I am a corporate president.In my mind,I am a game developer.But in my heart,I am a gamer.
名刺のうえでは、わたしは社長です。頭のなかでは、わたしはゲーム開発者。しかし、こころのなかでは、わたしはゲーマーです。
via Randy's Blog
Invalid media: image
读 React 18 文档有感
昨天 Sixian 提到了 React 的新版官方文档，之前一直没有去读，今天抽空读了其中 Escape Hatches 的部分，有一些收获，也有一点感想，在这里简单分享一下。
声明：我经常使用 React, 但我不是 React 的专家，我也不再是一个对技术会进行非常深入探究的人了。所以对于 React 最新的一些 API, 可能对某些人来说是老生常谈，但对我来说是新鲜的。所以本文只是简单分享一下我看到的之前不知道的一些 API.
跑两次的 useEffect
开发环境 useEffect 跑两次是故意的，是为了帮助开发者在开发环境中发现你是否正确地给你的 effect 做了 teardown.
讨论这样的特性是否是一种傲慢对我来说意义不大，重要的是我理解了其动机。
flushSync API
React 有一个 flushSync API, 可以强制 update DOM. 在以前我们一般是把希望在 DOM 更新后才执行的代码放在一个 setTimeout 里.
如果想重置一个 Component, 直接给它一个新的 key
如果希望某个 component 的 props 被改变的时候做一些重置，应该直接给这个 component 赋一个新的 key, 使 React 直接重建整个 DOM, 而不是用 useEffect 手动做重置工作。
其实以前我也经常这么干，比如 Modal 在关闭和打开后重置里面 Form 的值，我会直接给 Modal 一个新的 key. 一直不知道这是否是一个 best practice, 现在得到了官方认证。
useSyncExternalStore
这是一个我不知道的 Hook, 看起来很适合用于把别的库移植到 React 时使用，而且它对 SSR 非常友好。
一些感想
很多人觉得 React 繁琐，心智负担特别大，我也这么认为。但我一直觉得，这不是 React 本身的问题，而是 JavaScript 的问题。
React 是一个特别函数式编程思维的框架，但很可惜，JavaScript 只是一个半吊子的函数式编程语言，它只是在被设计的时候学了一点 Lisp 的皮毛，也提供了一点点函数式的 API, 但它没有很多真正的函数式编程语言应该有的基本特性，才导致了我们要写额外的代码来解决一些问题。
例如，Memoization 在一些函数式编程语言里是标配，但 JavaScript 里没有，所以你需要给函数手动套一层
函数式编程语言里, Immutable 也是标配，而在 JavaScript 里，需要用 Immer 之类的第三方库。
所以这就是为什么在多年前我很看好 ReasonML (现在叫 ReScript) 这个语言，因为它本身就是真正的函数式编程语言（它是基于 OCaml 的 JavaScript 方言），你会发现，用它来写 React 是多么舒服的一件事，因为语言本身就提供了你在 JavaScript 里需要调 API 才能实现的功能。有趣的是，React 在刚开始设计的时候用的就是 OCaml.
成也 JavaScript, 败也 JavaScript.
via Randy's Blog
Invalid media:
image
image
image
image
昨天 Sixian 提到了 React 的新版官方文档，之前一直没有去读，今天抽空读了其中 Escape Hatches 的部分，有一些收获，也有一点感想，在这里简单分享一下。
声明：我经常使用 React, 但我不是 React 的专家，我也不再是一个对技术会进行非常深入探究的人了。所以对于 React 最新的一些 API, 可能对某些人来说是老生常谈，但对我来说是新鲜的。所以本文只是简单分享一下我看到的之前不知道的一些 API.
跑两次的 useEffect
开发环境 useEffect 跑两次是故意的，是为了帮助开发者在开发环境中发现你是否正确地给你的 effect 做了 teardown.
The right question isn’t “how to run an Effect once”, but “how to fix my Effect so that it works after remounting”.如果你的代码因为 useEffect 跑两次所以出问题，很可能你用错了 useEffect.
讨论这样的特性是否是一种傲慢对我来说意义不大，重要的是我理解了其动机。
flushSync API
React 有一个 flushSync API, 可以强制 update DOM. 在以前我们一般是把希望在 DOM 更新后才执行的代码放在一个 setTimeout 里.
如果想重置一个 Component, 直接给它一个新的 key
如果希望某个 component 的 props 被改变的时候做一些重置，应该直接给这个 component 赋一个新的 key, 使 React 直接重建整个 DOM, 而不是用 useEffect 手动做重置工作。
其实以前我也经常这么干，比如 Modal 在关闭和打开后重置里面 Form 的值，我会直接给 Modal 一个新的 key. 一直不知道这是否是一个 best practice, 现在得到了官方认证。
useSyncExternalStore
这是一个我不知道的 Hook, 看起来很适合用于把别的库移植到 React 时使用，而且它对 SSR 非常友好。
一些感想
很多人觉得 React 繁琐，心智负担特别大，我也这么认为。但我一直觉得，这不是 React 本身的问题，而是 JavaScript 的问题。
React 是一个特别函数式编程思维的框架，但很可惜，JavaScript 只是一个半吊子的函数式编程语言，它只是在被设计的时候学了一点 Lisp 的皮毛，也提供了一点点函数式的 API, 但它没有很多真正的函数式编程语言应该有的基本特性，才导致了我们要写额外的代码来解决一些问题。
例如，Memoization 在一些函数式编程语言里是标配，但 JavaScript 里没有，所以你需要给函数手动套一层
React.useCallback.函数式编程语言里, Immutable 也是标配，而在 JavaScript 里，需要用 Immer 之类的第三方库。
所以这就是为什么在多年前我很看好 ReasonML (现在叫 ReScript) 这个语言，因为它本身就是真正的函数式编程语言（它是基于 OCaml 的 JavaScript 方言），你会发现，用它来写 React 是多么舒服的一件事，因为语言本身就提供了你在 JavaScript 里需要调 API 才能实现的功能。有趣的是，React 在刚开始设计的时候用的就是 OCaml.
成也 JavaScript, 败也 JavaScript.
via Randy's Blog
Invalid media:
image
image
image
image
2023 年终总结: 和自己对话
变化
2023 年初，持续了 3 年的疫情封控结束了，整个社会迎来了一个转变的开端，没人知道会变好还是变更糟糕。随后 3 月，我决定离开微软，我自己也迎来了一个转变的开端，我也不知道会变好还是更糟糕。
我财务自由了吗？如果财务自由有一个绝对值，那么无论是多少，我肯定都没有达到。离职后有很多朋友问过我这个问题，现在刚好可以在博客也跟我的博客读者分享：当我在考虑不工作时，我在思考什么？
1. 如果继续现在的状态，那么 3-5 年内我会有什么不同？
这是我在考虑是否入职微软之前用的同一个方法，是我朋友教我的。当年我觉得如果不入职微软见识见识，我一定会后悔，留在原来的公司也不会有太大的变化。今天即使我已经离职了，但我很感谢我有选择微软，我的收获非常多。所以我运用同一种决策方式来思考，即使我在微软继续工作 10 年，很大可能我得到的只是 title 和薪水的不同，这和我的目标背道而驰。这也引出了我的第二层思考：
2. 我正在做的事和我的长远目标是否对齐？
过去我会担忧和焦虑我达不到目标，后来我醒悟：没有人可以控制结果，只要我正在做的事是朝向我的长远目标就可以了。继续工作显然不是。
3. 没有固定收入怎么生活？
我有一点积蓄，虽然不多。很多人存了钱，买了房子。而我用我的积蓄买一段可以不工作的时间，我觉得还是很值得的。而且我不工作也不是天天躺着什么都不做，只要朝着我的目标在努力，这也算是一笔投资。
幸福之道
离开公司后，我的心情很复杂。我觉得我一直想寻找一个答案，但实际上我连问题是什么都不知道。我想起了年轻时读的《刀锋》，应该像书中的拉里一样去寻找，于是 7 月份我去了泰国，得到了一段出乎意料的佛教哲学之旅。
创造
今年的输出比我预期的要更丰富一些。
视频创作
继 2022 年的 Logseq 分享视频，今年又做出了一个超 50,000 播放量的视频《我如何做笔记》
《代码之外 Beyond Code》播客
今年终于和 GeekPlux 一起把盘算了多年的项目真正做了出来，意外地得到了很不错的反响。甚至能在线下聚会的时候听到一些我们的听众表达的感谢。
其实节目的制作形式受到了很多我喜欢的不同的播客节目，我由此也更深刻地感觉到，一个人能做出什么样的东西，很大程度上取决于其接触、输入的东西。只有吸收优秀的东西，才有机会做出优秀的东西。
这跟做产品也很像，如果一个人从来没有体验过真正优秀的产品，那就很难做出优秀的产品。所以我总是鼓励一些朋友，不要因为一个产品要花钱所以不去用它，就算只买一个月，也要去体验一下。
Randynamic Studio
离职后我就计划把我之后做的所有小工具统一到 Randynamic Studio 的名下. 很幸运，它的真正意义上的第一个产品 Notepal 算是非常成功。它没有为我赚巨额的钱，但它解决了很多人的需求，并且这些人愿意为它付费，这是我写在博客首页很多年的一个目标，在今年终于实现了。
多年来我把 Y Combinator 的 slogan 一直放在心中，有很长一段时间我每天睡醒后心里就会自动播放这句话：
线下聚会
解除封控后，终于可以参加一些技术圈子的线下聚会了，也有机会见到一些相识多年但从未谋面的网友。
先是参加了佐玩开发者交流会，见到了很多很年轻的后辈，更惊喜的是很多是《代码之外》的听众，他们都说在节目中收获到了很多。在那一瞬间我觉得我做的很多事情都是有意义的。
然后我到杭州找了图拉鼎，见识了数字游民的聚合地「玉鸟集」。在那里还认识了非常多的独立开发者和做产品的人，大家都很有自己的想法，对自己做的事情有自己的理解，有自己的观点，自己的品味。这种类型的朋友是很难在工作的时候遇到的。
总结
2023 是我和自已对话的一年，我开始了解自己想要的是什么，了解自己的情绪，了解自己擅长的是什么，不擅长的是什么，了解自己追求的是什么，等等。在清迈，我学会了倾听内心的声音，我也意识到，在真正了解自己的情况下，做决定似乎没有那么难了。
展望
我其实很希望在 2024 年能做一些 scope 更大的事情，同时也需要找到和我有相同 passion 的人。我一直不称自己为「独立开发者」，一是我觉得我还没达到，二是这也不是我的目标。我的目标一直是两三个有同样追求的人组成一个小 team 做一个美且在商业上可行的产品。
希望自己能往目标再迈进一大步。
via Randy's Blog
可在小宇宙收听本文音频版
变化
2023 年初，持续了 3 年的疫情封控结束了，整个社会迎来了一个转变的开端，没人知道会变好还是变更糟糕。随后 3 月，我决定离开微软，我自己也迎来了一个转变的开端，我也不知道会变好还是更糟糕。
我财务自由了吗？如果财务自由有一个绝对值，那么无论是多少，我肯定都没有达到。离职后有很多朋友问过我这个问题，现在刚好可以在博客也跟我的博客读者分享：当我在考虑不工作时，我在思考什么？
1. 如果继续现在的状态，那么 3-5 年内我会有什么不同？
这是我在考虑是否入职微软之前用的同一个方法，是我朋友教我的。当年我觉得如果不入职微软见识见识，我一定会后悔，留在原来的公司也不会有太大的变化。今天即使我已经离职了，但我很感谢我有选择微软，我的收获非常多。所以我运用同一种决策方式来思考，即使我在微软继续工作 10 年，很大可能我得到的只是 title 和薪水的不同，这和我的目标背道而驰。这也引出了我的第二层思考：
2. 我正在做的事和我的长远目标是否对齐？
过去我会担忧和焦虑我达不到目标，后来我醒悟：没有人可以控制结果，只要我正在做的事是朝向我的长远目标就可以了。继续工作显然不是。
3. 没有固定收入怎么生活？
我有一点积蓄，虽然不多。很多人存了钱，买了房子。而我用我的积蓄买一段可以不工作的时间，我觉得还是很值得的。而且我不工作也不是天天躺着什么都不做，只要朝着我的目标在努力，这也算是一笔投资。
幸福之道
离开公司后，我的心情很复杂。我觉得我一直想寻找一个答案，但实际上我连问题是什么都不知道。我想起了年轻时读的《刀锋》，应该像书中的拉里一样去寻找，于是 7 月份我去了泰国，得到了一段出乎意料的佛教哲学之旅。
创造
今年的输出比我预期的要更丰富一些。
视频创作
继 2022 年的 Logseq 分享视频，今年又做出了一个超 50,000 播放量的视频《我如何做笔记》
《代码之外 Beyond Code》播客
今年终于和 GeekPlux 一起把盘算了多年的项目真正做了出来，意外地得到了很不错的反响。甚至能在线下聚会的时候听到一些我们的听众表达的感谢。
其实节目的制作形式受到了很多我喜欢的不同的播客节目，我由此也更深刻地感觉到，一个人能做出什么样的东西，很大程度上取决于其接触、输入的东西。只有吸收优秀的东西，才有机会做出优秀的东西。
这跟做产品也很像，如果一个人从来没有体验过真正优秀的产品，那就很难做出优秀的产品。所以我总是鼓励一些朋友，不要因为一个产品要花钱所以不去用它，就算只买一个月，也要去体验一下。
Randynamic Studio
离职后我就计划把我之后做的所有小工具统一到 Randynamic Studio 的名下. 很幸运，它的真正意义上的第一个产品 Notepal 算是非常成功。它没有为我赚巨额的钱，但它解决了很多人的需求，并且这些人愿意为它付费，这是我写在博客首页很多年的一个目标，在今年终于实现了。
多年来我把 Y Combinator 的 slogan 一直放在心中，有很长一段时间我每天睡醒后心里就会自动播放这句话：
Make something people want.很幸运我朝着这一个目标又迈进了一步。
线下聚会
解除封控后，终于可以参加一些技术圈子的线下聚会了，也有机会见到一些相识多年但从未谋面的网友。
先是参加了佐玩开发者交流会，见到了很多很年轻的后辈，更惊喜的是很多是《代码之外》的听众，他们都说在节目中收获到了很多。在那一瞬间我觉得我做的很多事情都是有意义的。
然后我到杭州找了图拉鼎，见识了数字游民的聚合地「玉鸟集」。在那里还认识了非常多的独立开发者和做产品的人，大家都很有自己的想法，对自己做的事情有自己的理解，有自己的观点，自己的品味。这种类型的朋友是很难在工作的时候遇到的。
总结
2023 是我和自已对话的一年，我开始了解自己想要的是什么，了解自己的情绪，了解自己擅长的是什么，不擅长的是什么，了解自己追求的是什么，等等。在清迈，我学会了倾听内心的声音，我也意识到，在真正了解自己的情况下，做决定似乎没有那么难了。
展望
我其实很希望在 2024 年能做一些 scope 更大的事情，同时也需要找到和我有相同 passion 的人。我一直不称自己为「独立开发者」，一是我觉得我还没达到，二是这也不是我的目标。我的目标一直是两三个有同样追求的人组成一个小 team 做一个美且在商业上可行的产品。
希望自己能往目标再迈进一大步。
via Randy's Blog
复读和命运
冯大辉 Fenng 发了一条 Tweet 问
我当时考到的是二本，除了学费贵一点之外，我觉得都挺好的。我个人的浅见是，命运是没有人能预测的，复读和不复读是两个不同的分支。当然这说了等于没说。所以我来试试纸上谈兵一下：
我们假设复读一定能考上一本，那么我们可以把问题简单化为一个博弈：是否用人生的一年时间去换这个一本学历？
我有一个高中同学选择了复读，最后考到了比不复读更好的学校，但是在我对他的理解和我的个人认知里，他复读和不复读，并不会有很大的区别。
在我有限的经验观察里，人和人的距离，一本和二本的差距只占了非常非常小的部分，最重要的是人本身，他是否能客观地认知自己，自己的目标在哪里，想要的生活是什么，追求的东西是哪些。再以此为前提，是否能为了目标去努力地寻找资源，运用自己的主观能动性，去趋向自己的目标。然后在运气来临的时候抓住它。
就像有些人对我的评价，我「只不过是每次赶上了末班车」。我觉得这个评价很正确。我原本是 2018 年的大学毕业生，但我 2015 年就退学了。没有人知道我退学之后是好还是坏，我也不知道，但我们马后炮地回看，当时的时间点退学，让我赶上了互联网发展的「末班车」，如果我等到毕业，在这鼓浪潮开始退去的时候，我这个二本学生，不一定能混到我现在的状态，这辆「末班车」早就跑了。
我的例子不值得效仿，能不能坐上「末班车」，除了时机，还有我早就付出过的那些别人不一定看得到的努力。但我想表达的是，在做选择的时候，不能轻视了「时间」这个非常重要的因素。早一年和晚一年，会认识不同的人（这决定了人脉），会影响你身处在浪潮哪个位置，等等等等。
这个世界就是一连串随机事件的结果，它没有好坏之分，好坏都是靠自己的努力去定义的。如果这位朋友对自己的目标并不明确，那么早一年晚一年，好像也不会有什么本质上的区别，只要自己复读的一年里心理状态可以保持得很好，那复读也不是一个坏选择。
只有在「有目标 + 肯努力」的状态下，才能把人生这张彩票玩成一场能拿一手烂牌打赢的德州扑克。
via Randy's Blog
冯大辉 Fenng 发了一条 Tweet 问
对于各位高考过来人，如果成绩只能上二本，要不要复读？以下是我的想法。
我当时考到的是二本，除了学费贵一点之外，我觉得都挺好的。我个人的浅见是，命运是没有人能预测的，复读和不复读是两个不同的分支。当然这说了等于没说。所以我来试试纸上谈兵一下：
我们假设复读一定能考上一本，那么我们可以把问题简单化为一个博弈：是否用人生的一年时间去换这个一本学历？
我有一个高中同学选择了复读，最后考到了比不复读更好的学校，但是在我对他的理解和我的个人认知里，他复读和不复读，并不会有很大的区别。
在我有限的经验观察里，人和人的距离，一本和二本的差距只占了非常非常小的部分，最重要的是人本身，他是否能客观地认知自己，自己的目标在哪里，想要的生活是什么，追求的东西是哪些。再以此为前提，是否能为了目标去努力地寻找资源，运用自己的主观能动性，去趋向自己的目标。然后在运气来临的时候抓住它。
就像有些人对我的评价，我「只不过是每次赶上了末班车」。我觉得这个评价很正确。我原本是 2018 年的大学毕业生，但我 2015 年就退学了。没有人知道我退学之后是好还是坏，我也不知道，但我们马后炮地回看，当时的时间点退学，让我赶上了互联网发展的「末班车」，如果我等到毕业，在这鼓浪潮开始退去的时候，我这个二本学生，不一定能混到我现在的状态，这辆「末班车」早就跑了。
我的例子不值得效仿，能不能坐上「末班车」，除了时机，还有我早就付出过的那些别人不一定看得到的努力。但我想表达的是，在做选择的时候，不能轻视了「时间」这个非常重要的因素。早一年和晚一年，会认识不同的人（这决定了人脉），会影响你身处在浪潮哪个位置，等等等等。
这个世界就是一连串随机事件的结果，它没有好坏之分，好坏都是靠自己的努力去定义的。如果这位朋友对自己的目标并不明确，那么早一年晚一年，好像也不会有什么本质上的区别，只要自己复读的一年里心理状态可以保持得很好，那复读也不是一个坏选择。
只有在「有目标 + 肯努力」的状态下，才能把人生这张彩票玩成一场能拿一手烂牌打赢的德州扑克。
via Randy's Blog
