记一次大规模裁员事件

Share

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点多,这次裁员的影响逐渐被大家接受。让我真切的意识到,小小的打工人,在这种经济环境不好的时候,无力改变什么。时代的一粒灰,落到普通人头上,就是一座山。

这里只能借用秀才哥的一段话与诸位共勉。

资本本身是追逐利益的,没有人性。普通打工人最好早日看清资本的陷阱,不要把自己的精力都放在爬梯子上,那把梯子随时都可以撤走,只是有些地方做得比较体面罢了。投资自己,能随时炒老板。

另,新春快乐

Read more

低绩效同事,先别急着下结论

低绩效同事,先别急着下结论

团队里最难处理的,往往不是最差的同事,而是那些卡在board line上,挤挤能出活、但不挤就磨洋工的low performer 同事。 这类 low performer 一出现,很多Manager的第一反应就是:ownership 不行。问题是,这句话太空了,空到几乎没法行动。 我更喜欢用一个简单的框架看这件事:先判断原因,再调整支持,接着设观察期,最后做去留决定。 先判断:到底是哪一类问题 low performance 不等于 low ability。常见情况其实不一样: * 不会做:能力还没到,拆问题、推进、沟通都卡住。 * 不想做:知道怎么做,但投入不够。 * 做错方向:很努力,但目标理解偏了。 * 岗位不匹配:人不差,只是不适合这个角色。 比如: * 一个同事总是晚交,但每次都能把问题讲清楚,可能是任务切太大了。 * 一个同事总返工,

By andy

Vibe coding 之踩坑记

Vibe coding 对于程序员的技能要求反而比之前高了 先讲一个故事。 我这几天突然被隔壁组叫去,帮他们解决一个支付系统的问题。 简单来说,我们的客户分成机构和下属的医疗场所。一个机构下面可能有多个场所,然后机构可以统一管理下属场所的账单,支付等等。这样就需要我们能在我们的支付系统里面建立一个关系树,让父结点能看到子节点的账单,并支付。 问题就出在这个关系树上。因为我们之前用过一个另外的支付系统,所以有一部分老客户是从之前的系统迁移过来的。 这个老系统给每个客户创建了一个独特的id,但是这个id 和我们内部使用的id 并不一致,所以我们需要自己把客户的id 和他们的支付账户连接起来。然而: * 新的支付系统只支持固定的一些属性进行搜索。所以之前做这个项目的工程师A耍了个小聪明,用客户的last-name 属性存储了我们的id * 第一个雷:用户的last-name是可以由用户自行修改的。如果他们修改了,我们的对应关系就乱套了。 * 但是这个id A存错了,应该存储机构的id,A存成了下属场所的

By andy

关于flashblocks

争取整个短文系列,迎合短视频的潮流。 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), 这个预确认还没有状态更新

By andy