工作学习论

Share
特别鸣谢宫师姐校对

——甚至这个鸣谢也校对过了

今天突然想写点关于方法论的东西。

起因是组里有个小哥跳槽了。我和他一起做过他离职前最后一个项目——接触之后,我对他的离职早有心理准备。和他导师聊了之后,我们都觉得他缺少工作中学习的能力:和他工作非但没法把工作分出去,反而会给自己增加很多答疑的工作量。

细想之下,小哥在工作中体现出了学习能力和写作能力的不足,导致合作双方平添了许多不必要的工作。如果他能够做到会提问题,善用搜索,勤记笔记,我想我们的合作会更加愉快。

提问的艺术

刚开始工作的时候,我经常会问组里高工(Senior)一些很蠢的问题,要么是太泛没法让人回答(比如“Docker 是啥啊?”),要么是对方不知道从哪个角度来回答你(比如“我该咋用Docker部署啊?”)。在我读了《提问的智慧》之后明白了一件事:一个问题,你问的越具体,事前做过越多的研究,被问的人越好回答你。而越含糊,无脑的问题,别人越难回答。

“在for循环里应该用i++还是++i”就比“这个循环应该咋写”好回答。前者把问题聚焦到一个很小的范围,提供了上下文(是for 循环不是while 循环)并且给出了两个可选项。后者完全让人无法推测这个循环是干什么的。

小哥就经常问我很多含糊、不过脑的问题,让我很多时候不知道该怎么回答。比如:“我这个服务跑不起来”——然后我吭哧吭哧翻了半天日志发现他的启动脚本缺了个标志值;“我这个bug不知道怎么回事”——我去看了一下bug然后找到了问题。

工作中有问题,问题多本身不是一个问题,遇到问题也不要胆怯不敢问。不会问问题,或者说不动脑子直接把问题推给别人,这个才是问题。

主动的搜索

小哥还有一类比较频繁的问题就是“我在哪能找到X?”“这个标志值Y是什么意思”——基本上把X和Y 放到Google里就能直接搜索到结果或者文档。我有时开玩笑说我们都在Google工作了,遇到这类问题更应该支持自家公司的产品,多搜一搜,实在搜不到再问嘛。

在工作中遇到的至少50%的问题完全可以靠搜索引擎找到答案。当然,和上一个话题一样,问题越具体,关键字越多,找到你想要的答案的概率越大。

笔记的习惯

在刚开始工作的时候,我自己是没有做笔记的习惯的。直到我遇到一个有做笔记的习惯同事:他的笔记整理的很好,把他做过的项目细节都整理下来,然后把一些有必要的资料转换成文档。和他交流项目的时候完全可以直接去读他写的文档,然后把文档中有疑问的地方记下来,再单独问这些有疑问的地方。这样极大的节约了彼此的时间。

等到我开始实践记笔记时,才发现笔记这个宝藏真的应该从day 0 就开始记。这样不会因为自己没记住而重复的问同一个人同样的问题。

同样,笔记不单单可以记录工作,也可以用来记录一些突如其来的灵感。这些灵感有的可以加以转化成为新的项目,有些经过论证无效的也可以用作“前车之鉴,后事之师”。

以上是我觉得工作中非常有用的三个方面,写下这块砖,希望能“抛砖引玉”。

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