写在2022的最后一天

Share
每年写一次总结,就很grad

工作

2022年中,我从工作了三年的cloud转到了Geo。如果用三个关键词来总结2022的工作变动的话,我想应该是就是 responsibilityleadershipstrategic

responsibility

蜘蛛侠里有句著名台词,“能力越大责任越大”。这句话也同样适合放在工作中。

转到了Geo之后当了某个产品的负责人,自此对该产品有了“无限责任”。头脑风暴,写提案,写设计,拉客户,和其他组协调,调整项目优先级,分配项目等等等等很多之前工作中认为的“总会有人去解决的问题”,变成了“我会去解决”。

leadership & strategic

Strategic和leadership串起来一起看,就是因为责任大了,必须得要学会如何分配时间,考虑问题的时候需要抓大放小,把问题打包分配出去,并且还要考虑时序上的关系,确保大方向上我们和整个Geo保持一致。除了产品,改进组内文化,定期反思,改善工作流程,也是leadership的一部分。

同时,当负责人的第一年,思考问题的模式也有所变化。曾经作为纯IC(个人开发者),思考问题的模式是“这里有个模型,我照着它写就行”,“这个东西能跑就行”。而作为负责人,往往要更进一步问自己“这个模型合理吗?”,“这个东西能做的更好吗?”,“这个项目的优先级应该有多高?”,“产品在整个生态圈的什么位置?”,“我们的产品roadmap该怎么规划”。慢慢的把自己的思维模式从照着PRD做产品,转变变成做PRD和产品。

生活

生活上主要有两个小主题,健康与爱好。

健康

四月份的时候做了个体检,报告显示我某项指标有点高。在医生的建议下我把因为疫情停下来的健身捡了起来。经历了三个月的饮食健身改善,虽然体型体态上还是偏肿,但复检的报告显示比起四月的体检,健康状态有了很大的改善。也是以此为契机,恢复了常态健身的生活状态。

爱好

因为某名侦探朋友复归美,引起了我学习手冲咖啡的兴趣。作为一个装备党,我入手了一整套手冲咖啡设备并且学习了各种知识。然后就进入了“这个好酸啊”(买的浅烘豆子)“这个好苦啊”(粉磨太细了)等无尽的踩坑之旅。这里也发挥了理科男的思维模式,我找了咖啡豆的浸出速率曲线,通过理论指导实践的方法,调整水温,注水量,间隔时间等配合“控制变量法”来学习冲泡手法。

和“打了无数短点,加了无数日志之后找到了bug”一样,踩了茫茫多的坑之后,当我终于沖出来一杯口感醇厚,能喝出来豆子风味的咖啡时,那一刻的满足感和成就感令我觉得此行不虚。

总结&2023

总结完了我自己,给2023的自己一个小目标吧,希望自己2023多运动,多拍照,认真生活,认真享受生活。

Life is short, drink coffee.

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