点击蓝色“有关SQL”关注我哟
加个“星标”,天天与10000人一起快乐成长
听说蚂蚁金服上市后,不用再写周报了。全公司上下奔走相告,每个人好像比财务自由还开心。
听到这个消息,我低头思忖,蚂蚁恐药丸。这种体量的公司一旦上市后,掉以轻心,盲目自大,恐怕是要步史玉柱的“巨人网络”后尘,活成马老大曾说过的那个预言,“多数人死在明天的晚上”。
不计较上市“既得利益”,保持饥饿,继续追逐辉煌,才能守得住江山,持续创造价值。仔细盘一盘,国内上市后不套现的大佬没几个,而且国内也不常有 Goldman Sachs 一样的合伙人制度规约,反而因合伙人意见不同而频频造出丑闻的公司不少,好比某当的夫妻合伙档。
但,马上查阅内部人士流出的截图,似乎我这一波担心,是多余的。
image周报虽然取消,TL(Tech Lead)的月报还要继续。这当然是好事,蚂蚁的那颗炽热的红心还在。
有人可能会说,周报,月报是奋斗比的表现,卑微地讨好上级,不值得一提。还有同学会认为,革命成功了,财富自由了,应该好好享受生活。写周报就是虐待自己,该抛弃。
作为一名爱好写点豆腐块文章的小作者,写周报这事,我赞同蚂蚁的做法。应该积极鼓励周报制度,最好写日报。
前排的同学,板砖可以先放下。
后排的同学,F字可以先咽下。
我这么说,当然有足够的理由。不会写日报,周报,月报,惩罚会绵绵不绝地找上你。不错,就是惩罚。
我就是个典型的例子。
老读者都知道,刚工作那会,我是在电子厂写 MIS 软件的,也就是信息系统管理软件。当时的老板,主抓生产,没有从 MIS 看数据的习惯,需要什么数据,开个大会,把各个口子的负责人拉到一起,挨个汇报下,他就清楚了。
每个负责人都非常有规矩,一人一本,上面写着今天的日产,库存还有人工等等。那场面,就像美国人这次的安全部门开会一样,对答如流:
image引自:https://weibo.com/6479869715/IvYljlfNV?type=comment
如果你认为这一切,都是理所应当,那么回头找找黄冈卫健委的回答。
话说回来,每次开会,我是最紧张的一个。我既不懂生产,又不懂管理,写的软件,数据也没有获得老板重视,每次老板叫到,“ 小黄,你那边情况咋样,有什么要补充的么?” 我都只能耸耸肩,回答没有。顶多汇报下,报表打开慢,操作系统有病毒,或者新加功能什么时候能上线。
就这样过了两年后才发现,原来自己说不出来,真的是自己水平问题。我总想在当场就能口吐连珠,才思如喷涌,可平时没有积累素材,没有经过训练构思成文,没有真正自己演练过如何演讲,还要想着诸葛舌战群儒那份慷慨激昂,太天真!一口气怎么可能吃成胖子呢?这不是痴心妄想,是什么。
意识到这个问题后,我就开始写东西,写日报,写周报,写月报,写年终总结,还在博客写文章。
有时候在本子上用笔写,特别费劲。思维特别快的时候,码字儿速度跟不上,就写得特别丑,看着看着就没心情写,因为个人对美观还是挺看重,排版不好就能逼死我这个强迫症。于是换到电脑上写。那时候也没有云笔记,换电脑时,就经常丢笔记。换过至少5,6个本子,丢过的笔记不少。后来 有了云笔记,就一直没丢过了。
以下是我个人云笔记,大概3-4天会有一篇。如果有发表的必要,我就发布在公众号。
image甚至在代码里写注释也成为了我的爱好。和我工作过的朋友,可能对我代码印象不深,觉得晦涩,但往往都会觉得我的注释,非常舒服。就算有时候代码重构的太过风骚,但一步步的推进,用法,都会标有详细的注释。写代码要考虑到简洁,性能,还要考虑到后续维护的成本,万一别人看不懂怎么办。我记得半佛有句话,戏称 “ 我看众人兼 SB,我料众人看我亦如是 ”。这特么太写实了。
接下来的两年,老读者也清楚了,我把各类报表升级成了 BI 软件产品,嵌入到公司的 MES 里面。写了长长的介绍与操作指南,发给 MES 的各个用户(这里的用户大都是各个分公司分厂的厂长,制造经理,甚至是党委书记等等),几乎是一夜间,用户需求纷沓前来。
只见过文字,表格形式报表的老派用户,哪受得了可视化对他们的诱惑,各种图表制作都提了出来,这一仗算是打开了公司数据的 BI 化。平时瞅都不瞅我一眼的 IT 部经理,开会都点名安排我坐在他身边。自那开始我知道,该找个更大的平台了。
虽说这是微不足道的小事,但至少给了几个启发:
1) 平时注意收集项目中的素材,包括风险,进度,技术难点,行业动态和故障克服方法,对此多做总结,等到有机会汇报给老板时,才更有底气。自己贡献了多少,怎么做的努力,形成什么样的理论和实践方法,都可以分享给老板。有时候老板未必知道我们做了多少工作,尤其在人多的情况下,我们贡献了什么样的价值,老板并不能清晰的知道。这时会叫的孩子有奶喝就成了常态,与其让老板去回忆,去思考你的价值,那不如我们写出来,直接跟老板沟通。
2)我观察,周报的时效性远小于日报。程序员在接收工作任务时,往往以小时为单位。比如 4 小时解决一个 bug, 32 小时完成一个中等量级的任务。64 小时完成一个 sprint. 如果一周做一个 sprint,可能你还知道这周干了什么,用到了什么技术,哪些方面自己不熟悉。假如一周尽在修 bug,修了 10 来个,痛苦的要命, 但在复盘的时候,什么都想不起来。自己先想下,是不是这样。你还能记得上一个 bug 产生的原因,以及修复的方法吗,知道怎么去防止这类bug再次产生,有没有一个清晰的路线?这其实都需要记录。
3)编程是个多元化的工作。如果任由自己整天处在救火之中,不给自己留时间放空,我们就无法开启下一段的旅程。整天在处理 CRUD 的工作,而没办法去深入研究各类数据模型,数据库内部原理,那么我们积累的那点小知识,小技巧,早晚会被年轻而聪明的后浪给超越。而日报,周报留给我们的,就是很清晰的一个复盘资料。哪怕那天没记录,也至少知道一周中是不是无效时间拉长了,接下来怎么去弥补。当回头审视自己的任务时,发现这段时间一直在处理 sql 的事情,而对 big data, BI, AI 都没有更好的扩充积累,那么很快就会提醒自己,该看点别的什么了。
4)团队的协作更高效。团队之间协作高效的方式有很多,最杀时间,最无效的便是毫无意义的多人大会。往往老板没想好主题,团队也没对事情有充分的预热,就硬凑着一帮人开会,结果张三李四都插一句,事情没啥进展,还浪费一拨人 2-3 小时的生命。如果采用异步的文字分享和预热,比如分享周报,绝对是特别有意义的事情。当年很多工作的同事,看了我的分享邮件,知道有个 BI 的东西正在流行起来,于是尝试在各自的分管部门推一推,做一做,最终才促进了整个公司的 BI 进程。你看,就是不经意同事或朋友们的一封邮件,一个总结,就能有一个创意,打开自己的思路。所以我建议,积极地靠近有想法,会创造的同事,朋友,他们往往都是灵感之泉。
在写周报这方面,尤其对于程序员,我觉得大家还是尽量逃离舒适区,好好写,不搞形式主义,不讨好谁谁谁。我也在努力,你看公众号大部分文章都是我的个人总结,都是原创,如果不写,怎么培养自己思考,说话和演讲的能力?
通过写文章,不断迭代修正自己的思维产品,这产品的好坏,直接决定自己的价值。
谁都不愿意成为第二个张飞吧:
--完--
往期精彩:
本号精华合集(二)
如何写好 5000 行的 SQL 代码
如何提高阅读 SQL 源代码的快感
我在面试数据库工程师候选人时,常问的一些题
零基础 SQL 数据库小白,从入门到精通的学习路线与书单