不知是否很多人都和我一样，曾在儿时憧憬成年，幻想过成年后自己的生活。梦想的职业从科学家，到被选召的少年，再过渡到社畜。也是从懵懂无知，到幻想主义，到现实主义一步步蜕变。
人生有几个常常被赋予特殊含义的年龄，比如十八，三十：一个是生理上发育结束；一个是社会发育结束。
站在二字头的岁数，每年都掐着指头算离三字头还有多远。二十出头曾幻想三十岁的自己应该身家过亿，挥斥方遒；差五天满三十岁时，正在拉excel算怎么投资退休金能少交收入税，再根据银行户头余额制定购物计划。此时身家离过亿少了一个亿左右。再回头看二十岁的自己，恍惚觉得自己读懂了史铁生的“看透生活并热爱生活”：经管我还看不懂它，但我依旧热爱它。
今年也是第一次在圣诞节收到了泡脚桶这种“保健养生”类产品。联想到了呼兰说他31岁生日收到的祝福从“生日快乐”变成“身体健康”。三字头的阶段看来更多转成“攘外必先安内”了。
2020是一个低谷，这一年经历了太多“百年未有之大变局”。触底一年，希望2021年是一个触底反弹局。在此，也祝身边的朋友们2021年事事顺心，身体健康。
团队里最难处理的，往往不是最差的同事，而是那些卡在board line上，挤挤能出活、但不挤就磨洋工的low performer 同事。 这类 low performer 一出现，很多Manager的第一反应就是：ownership 不行。问题是，这句话太空了，空到几乎没法行动。 我更喜欢用一个简单的框架看这件事：先判断原因，再调整支持，接着设观察期，最后做去留决定。 先判断：到底是哪一类问题 low performance 不等于 low ability。常见情况其实不一样： * 不会做：能力还没到，拆问题、推进、沟通都卡住。 * 不想做：知道怎么做，但投入不够。 * 做错方向：很努力，但目标理解偏了。 * 岗位不匹配：人不差，只是不适合这个角色。 比如： * 一个同事总是晚交，但每次都能把问题讲清楚，可能是任务切太大了。 * 一个同事总返工，
This is Andy's base: Tech, AI, Career, a brand new site by andy that's just getting started. Things will be up and running here shortly, but you can subscribe in the meantime if you'd like to stay up to date and receive emails when
Vibe coding 对于程序员的技能要求反而比之前高了 先讲一个故事。 我这几天突然被隔壁组叫去，帮他们解决一个支付系统的问题。 简单来说，我们的客户分成机构和下属的医疗场所。一个机构下面可能有多个场所，然后机构可以统一管理下属场所的账单，支付等等。这样就需要我们能在我们的支付系统里面建立一个关系树，让父结点能看到子节点的账单，并支付。 问题就出在这个关系树上。因为我们之前用过一个另外的支付系统，所以有一部分老客户是从之前的系统迁移过来的。 这个老系统给每个客户创建了一个独特的id，但是这个id 和我们内部使用的id 并不一致，所以我们需要自己把客户的id 和他们的支付账户连接起来。然而： * 新的支付系统只支持固定的一些属性进行搜索。所以之前做这个项目的工程师A耍了个小聪明，用客户的last-name 属性存储了我们的id * 第一个雷：用户的last-name是可以由用户自行修改的。如果他们修改了，我们的对应关系就乱套了。 * 但是这个id A存错了，应该存储机构的id，A存成了下属场所的
争取整个短文系列，迎合短视频的潮流。 base前段时间整了个活，提出了一个新的概念叫flashblocks。 在有flashblocks之前，每个区块的状态是要么这个区块还不存在，没法拿到区块的任何状态和信息；要么就是这个区块已经存在了，它的状态是不可变的，拿到就是最终区块。base链每2秒产生一个新的区块，即任何的交易需要2秒钟才能确认。 如下图，区块A生成之后，2秒内用户只能看到区块A，直到区块B生成。 flashblocks呢，它允许用户提前获取正在打包的区块的状态。正在打包的区块每200ms更新一次状态，直到10次更新之后，正在打包的区块变成一个完整的区块。 如下图，区块A打包200ms后，用户可以立刻看到区块B的状态0. 再200ms后，可以看到区块B的状态1，直到区块B的状态9，然后区块B稳定，开始生成区块C的状态1。 flashblocks的好处是什么呢？它可以在一个区块完全打包好之前，让用户提前知道自己的交易是否有被打包进当前的区块，加速交易状态的确认。 缺点又有哪些呢？ 首先这个确认属于预确认（preconfirmation）， 这个预确认还没有状态更新