2026-06-17 04:54:00
最近在新的组工作了一段时间，总结下最近的进展并且记录下来。
[Revised by ChatGPT]
亚马逊有一个非常重要的 Leadership Principle：
Insist on the Highest Standards
很多团队的问题并不是不努力，而是默认接受了较低的质量标准。
高标准不是等到上线前再检查，而是体现在每一个日常环节：
我越来越相信：
质量不是测试出来的，而是在整个开发过程中设计出来的。
当团队对于代码质量、文档质量、设计质量都有明确要求时，长期来看反而能够提升开发速度。
因为技术债务减少了，返工减少了，团队成员之间的信任也更高。
高标准短期看似更慢，长期却是最快的路径。
很多项目失败并不是因为方向错误，而是因为交付周期太长。
亚马逊强调：
Deliver Results
但优秀团队的特点并不是一次性交付一个巨大的项目，而是持续不断地交付价值。
我的经验是：
与其规划一个 6 个月后才能看到结果的大项目，不如拆分成多个两周或者一个月就能验证价值的小阶段。
例如：
这样既降低风险，也能够更快获得反馈。
其实你会发现 1 和 2 是有一定矛盾的，高标准很可能拖慢速度。所以我们需要可行的方法，我现在个人感觉最好的方法就是
每周是否有看得见的输出？
我越来越重视一个简单指标：
每周是否有看得见的输出？
这里的输出可以是：
如果连续几周都没有可见成果，往往意味着：
而持续输出能够形成正反馈：
输出 → 获得反馈 → 调整方向 → 继续输出
久而久之，团队会形成一种健康的执行文化。
相比年度规划，我更关注：
本周创造了什么新的价值。
今年最明显的变化，是 AI 已经从一个辅助工具变成了一种新的工作模式。
过去的思考顺序通常是：我该怎么做？
现在更应该先问：AI 能帮助我完成哪些部分？
例如：
哪些部分可以用 AI 来辅助，我个人体会几乎所有任务 AI 都可以完成了，当然质量如何取决于你的任务复杂度，需要你提供 context 和 review。
AI First 并不是让 AI 替代工程师。相反，它让工程师把更多时间投入到：
这些真正高价值的工作上。
未来几年，人与 AI 协作的能力，很可能会成为工程师的重要竞争力之一。
很多工程师习惯埋头做事，却忽略了成果传播。
亚马逊另一个重要原则是：
Earn Trust
而建立信任的重要方式之一，就是让别人看到你的成果。
过去一段时间里，我越来越重视：
这些活动的价值不仅是汇报工作。
更重要的是：
很多时候，一个优秀的 Demo 所带来的组织影响，甚至超过几个月的默默开发。
好的工作需要被完成。
优秀的工作需要被看见。
回头看，这些原则其实都不复杂：
它们共同指向一个目标：
在保证质量的前提下，加快反馈循环，并不断扩大个人和团队的影响力。
对于工程团队而言，真正的竞争优势往往不来自某个单独的技术突破，而来自一套能够长期复利的工作方式。
而高标准、快速反馈和持续学习，正是这套工作方式的核心。
2026-04-06 06:54:00
之前的 RIF 我写了个总结，但是因为各种事情，我拖到今天才开始写。也不太想改动当时写的东西——虽然写得非常潦草，但确实是当时的感受，还是留着。Retro of RIF
这篇 Blog 重新总结下自己最近的感悟和体会，既是总结复盘，也是对未来重新计划。总结这七点，既是对 Q1 的复盘，也是对 Q2 乃至全年的行动指南。与其焦虑变化，不如主动适应。
AI 替代的趋势越来越明显，刷题不能停。你需要达到的水平是：如果今天被 impact，明天去面试，要有把握能拿到 offer。
重点方向：
虽然不一定喜欢这种节奏，但按照现在 AI coding 的趋势，将来每个 SDE 每年的 CR 数量可能超过 365 条——也就是说，每天提交 CR 将成为默认预期。
现在开始养成这个习惯，是为将来做准备。
最近公司甚至要求 manager 也要提交 CR。这意味着 SDE 不能再固步自封：
你的 Domain Knowledge 会越来越值钱。AI 干活比你快、比你好，它们干不好的唯一原因是缺乏 Context。所以提升领域知识深度，是你最核心的护城河。
过去四年，manager 在 Irvine，上班节奏相对自由。但现在不同了——manager 就在 Austin。
让别人记住你、了解你，比单纯埋头干活更加重要。调整作息，提高在团队中的存在感和影响力。
你必须有自己的 AI / LLM 相关项目，并且能够清晰地追踪和展示它的进展。
这是 Leadership 当前最关注的重点，也是证明自己与时俱进的最直接方式。
很多时候我们只关注手头的任务，但在 AI 时代，提升看问题的视角变得越来越重要。
Big Picture 不会带来立竿见影的提升，但它能帮助你更准确地理解问题的本质。
遇到问题，多问一句：“这是为什么？”
现在需要的不只是某个领域的 Expert，而是一个能够领导 AI、协调全局的多面手。
就像驾驶一样——安全驾驶，不冒险。
现在做的是 Payment System，安全是重中之重。在多种技术方案并存时，优先选择更稳健、更安全的路径，而不是追求激进或炫技的方案。
2026-02-03 04:54:00
最近读完了 硅谷Python工程师面试指南：数据结构、算法与系统设计。 在豆瓣已要求实名记录阅读的情况下，还是用博客写书评吧。
内容由 ChatGPT 生成，大纲是我提供的。
不必读，这本书内容选材不错，但是制作粗糙，帮助不大。
这本书的角度还是不错，编程基础，算法，系统设计都有讨论到。
但是，制作非常粗糙。很多时候，结合和 Leetcode 题目来讨论，本来是非常好的思路，但是作者明显用心不足。
算法的解释，很多就是简单的copy来的，或者看着 Leetcode 答案编写的，还是暴力英译中。你越看越糊涂。
更重要的是，很多代码格式错误，对于 Python 缩进如果错误，那就是非常致命的错误。
还有，如果可以，是不是可以给题目，添加一个 Leetcode 链接？ 很多题目的描述，我作为中文母语读者都无法理解。
还是可以读一读，但是大概就是半小时那种。
非常的浮光掠影，蜻蜓点水，帮助不大
非常不推荐，帮助不大。
2026-01-31 06:54:00
深刻反思下 RIF，现在还在 wrap up，但是这里先总结下。
别人提醒，要时刻反思，居安思危。
“思危、思退、思变”是需要每周都做的必修课。
最近打印照片，需要在背后写点东西，我想到了可能写错，当时还测试了好久，还是错了。其实多打印两张照片没多少钱，我却没想到，还是傻傻打印了固定份。
不要怕备份！
寄快递也是，地址 UPS 人员少打了 Building A，虽然东西后来也送到了，但是如果是真是十分重要的文件，还是一模一样的复用别人给的地址最好。我是后来检查发现的，但是更好的方法应该是当场让他们改进，这是最好的！
不要怕检查，当面检查，交割清楚！
Lucas 是我的一个同事，说话非常慢，但是就是给人很可靠的感觉。
感觉我就是需要联系这种能力，很多时候，你需要慢下来仔细思考才行。
2026-01-16 06:54:00
父母最近来美国,已经有 5 年没见过爸妈了。五年时间,不知不觉间父母的鬓角又添了几缕白发，妈妈的腰也弯得厉害。
给父母购买机票时,建议优先考虑直飞航班,比如上海到达拉斯的直飞航班,可以避免转机的麻烦。如果确实需要转机,香港是一个很好的选择——中文环境下沟通无障碍,父母也更容易适应。相比之下,首尔或东京等非中文机场可能会给父母带来语言不通的困扰。
美国机场普遍提供免费 WiFi 服务。务必提前查询好机场的 WiFi 连接方式,并详细告知父母如何操作。连上 WiFi 后,父母就可以通过微信随时保持联系,这对于缓解他们的紧张情绪非常有帮助。
中国机场的 WiFi 通常需要手机号验证,不过父母来美国时会保留国内手机号,这点不用担心。
建议提前为父母准备一些美元零钱,比如:
这样父母在机场可以方便地购买咖啡、瓶装水,或者在需要时打电话,不必为找零或使用大额纸币而烦恼。
如果是在美国机场送机,强烈建议在值机时申请 Gate Pass。我在美国办理过这项服务,至少美国航空(AA)是免费提供的。
有了 Gate Pass,你就可以陪同父母通过安检,一直送到登机口。对于不熟悉全英文环境的父母来说,能有人陪伴到最后一刻,会让他们更加安心,你也更加放心。
2025-12-28 06:54:00
When filtering data based on exclusion criteria, the choice between NOT IN and LEFT ANTI JOIN can significantly impact query performance. This post demonstrates why LEFT ANTI JOIN is typically the better choice.
< Revised and generated with help of Claude >
SELECT product_id, product_category
FROM products_dim
WHERE region_id = 100
AND product_id NOT IN (
SELECT product_id
FROM products_dim
WHERE region_id = 200
)
AND product_category IS NOT NULL
SELECT a.product_id, a.product_category
FROM products_dim a
LEFT ANTI JOIN (
SELECT DISTINCT product_id
FROM products_dim
WHERE region_id = 200
) b ON a.product_id = b.product_id
WHERE a.region_id = 100
AND a.product_category IS NOT NULL
Both queries return exactly the same result: products from region 100 that don’t exist in region 200.
| Aspect | NOT IN | LEFT ANTI JOIN |
|---|---|---|
| Performance | Slower, less optimized | Faster, better optimized by Spark |
| Broadcast Risk | Can trigger unwanted broadcasts | Better control, prevents large broadcasts |
| Execution Plan | Subquery execution | Efficient join strategy |
| NULL Handling | Unpredictable with NULLs | Predictable behavior |
LEFT ANTI JOIN prevents broadcast errors while delivering the same results faster. When working with large datasets, this optimization can make a substantial difference in query execution time and resource utilization.
