Vibe coding 对于程序员的技能要求反而比之前高了 先讲一个故事。 我这几天突然被隔壁组叫去，帮他们解决一个支付系统的问题。 简单来说，我们的客户分成机构和下属的医疗场所。一个机构下面可能有多个场所，然后机构可以统一管理下属场所的账单，支付等等。这样就需要我们能在我们的支付系统里面建立一个关系树，让父结点能看到子节点的账单，并支付。 问题就出在这个关系树上。因为我们之前用过一个另外的支付系统，所以有一部分老客户是从之前的系统迁移过来的。 这个老系统给每个客户创建了一个独特的id，但是这个id 和我们内部使用的id 并不一致，所以我们需要自己把客户的id 和他们的支付账户连接起来。然而： 结果显而易见：我们的客户关系乱成一团麻了。没有任何关系的下属机构之间能看到相互之间的账单；有关系的机构和下属机构变成最熟悉的陌生人了。 我急忙忙的出了个方案，花了10几个小时修好了逻辑和数据。 在复盘整个事件时，最初的设计一眼看去就是vibe coding生成的。然后A又没有去验证方案的正确性，一路回车按下去，导致最后生成了一套四不像的方案。A接着无脑就照着这套方案去做了，完全没意识到有任何问题。 后续的修复方案，加上数据修复所花的时间其实比推倒重做还费时。奈何已经在生产环境的支付系统不允许我全推倒重做，只能一步步修复数据，然后改实现，测试，然后部署。 就这个简单的例子来看，vibe coding确实在生成方案时极大的提升了工程师的效率。就是“我有个想法，你看着实现“，AI就能生成一个九成真一成假的方案。但是最要命的也就是那一成假，可能把整个系统带到沟里去。后续修复的人力成本也比早期多花一些时间论证项目可行性高很多。 vibe coding […]

争取整个短文系列，迎合短视频的潮流。 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）， 这个预确认还没有状态更新。实际区块的状态更新依然要等待当前区块完整打包结束。也就是说只有预确认没法立刻进行下一个相关交易。 其次，这个flashblocks 只能在rollup L2上实现，因为只有有中心化的sequencer才能保证在打包中的区块状态是可控的；在L1上是没法实现，不同矿工之间不会每200ms就共识出来一个新区块的状态。

Resources for IC6(Staff) Eng interview preparation

1月19日 19号的时候，我有个同事从国内刚回美。我们约了半个小时的1:1。期间，聊到了在当前经济形势下，Google会不会像其他科技公司一样大规模裁员。当时我跟他说，裁应该是裁的，不过他本身rating还不错，做的项目也很重要，就算裁员应该也不会裁到他头上的 1月20日 从早上6点多开始，我就陆续收到微信消息，不过因为手机是静音模式，直到7点才被推送消息提醒。看着20多条未读消息，我第一反应就是“国内朋友们在提前发红包么？” 点开消息，发现内容都在讨论Google裁员。我脑子当时嗡了一下，闪过两个念头：1. 我这么乌鸦嘴？2. 我没被裁吧？ 急忙忙的点开邮箱去搜Sundar的邮件。他在凌晨两点多发了一个关于全球裁员12000人的邮件。再点开内部群，微信群，看同事们都在讨论怎么知道自己有没有受到影响。 10点多的时候，各路消息灵通人士们大概总结出来几种方法看自己是否收到影响：比如有没有收到hr的邮件；是否还能访问内部系统等等等等。多方验证之下我大概可以确定我暂时没有被影响到。 暂时确认后，心情稍微平复了一下。从早上刚听到消息时的茫然，震惊，变成三分侥幸，七分慌张。侥幸自然是因为苟过了这次裁员，慌张则是因为不知道这12000人是分批次裁员，还是一次性被裁，以及会不会有下一波裁员。 12点多，从老板那里听到一些管理层的消息，大意就是如果现在没收到邮件，那就安心搬砖吧，但是这种情况哪里安心的下来。组里另一个同事问我原定4点的会能不能提前到1点半，因为无心工作，想早点开完好下线休息。 下午2点多，从各路渠道听说了被裁的几个熟人。听到裁员的消息和知道认识的人被裁是完全不一样的。前者只是让人紧张但缺少实感，后者则让人更具体的感觉到裁员就在身边。 到了晚上8点多，这次裁员的影响逐渐被大家接受。让我真切的意识到，小小的打工人，在这种经济环境不好的时候，无力改变什么。时代的一粒灰，落到普通人头上，就是一座山。 这里只能借用秀才哥的一段话与诸位共勉。 资本本身是追逐利益的，没有人性。普通打工人最好早日看清资本的陷阱，不要把自己的精力都放在爬梯子上，那把梯子随时都可以撤走，只是有些地方做得比较体面罢了。投资自己，能随时炒老板。 另，新春快乐

关键词：疫情 2021年元旦的时候，我曾写过2020年是过的最没有实感的一年。因为疫情，从三月开始就居家隔离；每天过着睡觉和工作的两点一线的生活。没想到2021重复了2020。更糟糕的是，2021年里我们见到了两次抗疫胜利的“曙光”，却分别被delta和omicorn给打了回去。以此来看，距离疫情胜利，一切恢复正常依旧遥遥无期。 2020年曾有专家预测过疫情可能会在2025才完全结束。只能做好继续抗疫3年的心理准备。 关键词：工作 对我来说，过去的一年在工作上，算是收获的一年：项目推进顺利，经理认可，升职成功。 当然，每次都要甩出Ben Parker那句名言，能力越大责任越大：工作上也是如此。从负责一个人做的小项目，到负责几个人做的中型项目，越来越意识到交流，流程，文档的重要性。希望在2022年在工作上能继续保持劲头，争取再进一步。 关键词：生活 去年一年，随着fed的无限QE政策，我也是亲眼见证了：物价飞升，排骨从3块一斤涨到7块一斤，苹果也从9毛9涨到3块一斤；车市紧俏，疫情前买车是可以和dealer降价的，现在是要和dealer加价的；房市一路疯长；股市屡破新高。 现金贬值，对于我这种负资产阶级应该是好事，但是没有gdp支撑的qe又会在何时泡沫碎裂呢？ 关键词：海淘 自从奥利奥来家里之后，我们就逐步的开始了反向海淘：从淘宝买宠物用品然后寄到家里。 海淘的真相令人动容：美国的宠物用品符合（美观，实用，廉价）原则，而淘宝随随便便就能买到集三者于一身的宠物用品。 随着疫情导致的劳动力不足，海运的周期从2周逐步变成到2个月，而且运费从一斤13涨到了一斤18。大大的增加了我们海淘给奥利奥添置新皮肤的成本。 希望新一年里这种海淘贵，海淘慢的现象得到有关部门的注意，并得到治理。 写在最后 最后扣题一下，祝大家新的一年事事顺心。并祝我自己生日快乐😁

升职不写博客，如衣锦夜行 距离上次写blog有大半年了。这段时间里一直在急忙忙的弄升职的事。直到昨天收到通知：升职通过，心里一块大石头落了地。 与其他的同事相比，用了5个Cycle(每个Cycle 半年)升职的我属于不长不短，恰在中游的位置。但是两年半的过程中，我经历了一系列变动：领导A在一年半时跑路；然后等来了领导B。好不容易和B制定了一系列的升职计划，进行到八个月时B又转去做其他领域；纠结继续按计划执行还是观望的时候迎来了新领导C。运气比较好，C还是很认可K的计划并帮助我在最后三个月里尽量完善升职资料，最后顺利的升职了。 下面来总结一些我认为有用，并行之有效的干货。 对项目要有Ownership Ownership 名词。物主，身分，所有；所有权。 每次和我老板1对1聊天的时候，他总是强调要有项目的Ownership。起初我对这个很不以为意：做项目，有Ownership不是很应该的吗？但是随着参与进各类不同的项目之后，我发现每个人对Ownership的概念是不一样的。 有些人做项目做到一半，遇到一些来自其他组的阻力(blocker)后就原地躺平等别人来推动项目；有些人遇到阻力之后会积极的和其他组开会，达成共识，移除这些阻力。在绝大多数语境下，后者是对项目更有Ownership 的表现。而且要知道，对于升职的相关的项目，除了当事人之外没人会在乎项目进度与交付。所以对项目有Ownership，能更快的交付项目。项目好，你也好。 兼听则明，偏信则暗 我在开始执行升职计划的一年里，通过各种渠道找了三个导师(mentor)。一个是同组(org)的，一个是同大产品组(PA)的，和一个其他产品组的。每半个月会和三个导师分别聊半个小时左右。 有三个导师的好处就是，对于同样的一个问题，你能听到三个不同观点的反馈。并且他们会根据我自己的工作进度，职业规划给出一些很具体的建议。这样在遇到项目管理，项目选择等问题时我会有更多的信息来参考。当然，因为每个组和产品组之间的差异，不同的反馈也各有偏差。比如做应用与做底层之间对于同一个项目会有不同的难度系数。有时太多信息的反而会干扰决策。所以导师的数量和背景就需要个人的把握。 有效的文档 在谷歌，有一条广为人知的新人求生准则就是“多写文档，文档多多益善”。甚至有些走火入魔的同事们遇上个大事小情都要写文档，为了写文档而写文档。然而很多文档本身并没有太大的意义/作用。 有些文档是拿来做记录的，比如重点报告(one pager)，可以写的很潦草，注意力放在要讨论的问题本身，不需要太多引用，也不用填充太多的细节；有些文档是拿来做实现参考的，比如设计文档(design doc)，要写的很细致，引用证据丰富，并且逻辑上尽量无懈可击；有些文档是拿来协作的，比如会议记录(meeting note)、项目计划(rollout