More than code

More Than Code
The efficiency of your iteration of reading, practicing and thinking decides your understanding of the world.
  1. 首页
  2. 周报
  3. 正文

0414周报

2024年4月14日 339点热度 0人点赞 0条评论

打算继续开始写一写周报回顾一下自己一周做了什么事情,从而提高下自己的思考质量。不断的回顾反思我目前认为是最好的深入思考的方式,也就自然成了最快的成长方式。

大概在两年前,我还没有工作的时候,还会持续的写周报,记录每周的事情,但是从工作后就逐渐忘掉了这个习惯。最近读到的GTD书中也说到建议一周进行一次回顾反思,看看这一周自己干了什么,下一周要干什么,检查一下自己的checklist,看看各个层次的目标有没有正在达成。

非常细节的工作内容就不在这里提了,偏个人一点的事情再说细节点。

工作上整体这周事情偏多一些,能够集中精力做事情的时间并不多,大部分的时间还是在运维以及排查线上问题。不过自己也开始逐渐尝试站在一些稍微高层视角一些的地方开始看待事情,这是因为个人感觉+前辈的认可,感觉自己可以处理团队中遇到的大部分事情,这时候就需要看哪里是缺口,哪里相对薄弱,自己就要去哪里进行补足。事必躬亲的做法是不可取的,因为事情实在太多了,自己无法hold住整个团队每一个细节,就需要有一些侧重点,然后把精力投入到带领/强化其他同学的地方,来保证团队的发力效率。

这里有一些值得深入说一些的,就是事情多起来后,需要能够判断优先级,个人认为这里不是事情的优先级,对于重要的事情可以多关注,但是不需要真的自己上手去搞。保证对大体有一定的掌握即可,然后了解每个同学的能力边界,将合适的任务分发给适合的同学,并给予指导/培养,然后对于比较困难/非常紧急的问题可以灵活考虑,再自己上手去做。那么这里关键的有几个点:
* 需要明确每个同学的能力边界,保证不分发超过能力边界过大的任务,避免影响士气,也影响效率。这里就需要保持与其他人的联系,了解大家都在做什么,对自己手头上的事情的看法等,进行综合的评定。
* 对团队整体目标明确,保证自己可以做到救火队员,准确补位其他人的能力。

对于项目的推进来说,自己应该有一些定位上的转化,对排查问题等应该传授经验,提高效率,不需要每个问题都了解的非常细节。然后对于一些关键代码要保证质量,保证review到位,把控好代码的可维护性,避免背负过多的技术债。
* 即将重心从排查具体问题转移到代码质量的把控,因为这是一个更加长线,并且需要的整体素质更高的需求。

对于运维来说,应该有一些适当的offload,以及批量处理。在这周已经开始逐渐的尝试批量处理问题了,相对来说运维效能有一定提升,但不算多。个人认为这里还是有一些可以提升的点的:
* 对于常用操作,加速操作。比如一键xxx,利用alfred加速自己的各种操作。每一个可能阻塞的点都可能导致注意力分散,降低效率。
* 保证上下文切换尽量较少。应该添加一个context区域,每当开始做事情就放进去。新启动事情的时候则要看一下自己的context,避免不断切换任务导致效率下降。
* 日常打字偏多,可以尝试提高一下打字速度,提高整体的效率。比如练习一下双拼

个人成长的话,这周本来预期读完GTD,但是平常晚上回家基本上没有精力去读一些偏知识性的书了,所以并没有搞定,而是用了周末的时间读了读。目前还剩最后的1/5。下周搞定

GTD中讲了很多具体的例子,不过他的核心思路主要是:让大脑思考,而不是记忆一些细节的琐事。把自己从琐事中抽出来。

这里还引出了我另一个思考,就是LLM和目前的RAG的关系,LLM就像是大脑,主要是思考,而RAG则是辅助记忆的。

这周本来打算推进的业务梳理是一点进展都没有,一来是自己之前定的计划过于激进。二来是平常抽出来的时间也确实不多。

有关最近推进的第三个项目,Transactional Information System的学习,这周并没有很多进展,不过利用书中知识回答了个问题,也算是有一些实践了。相关实践应该更多一些,加深自己在这块的理解。

整体来说个人近期打算推进的项目都多多少少有一些delay。主要还是上面说的,对平常自己的精力预估太乐观了,基本上晚上到家就没什么很多精力去学习了。这周打算调整一下计划:
* 先把GTD收尾
* TIS书的学习比较困难,放到早上
* 晚上做一些信息收集的工作,如业务梳理需要涉及到大量的信息收集,可以放到晚上整理。
* 开启一下新的晚上的项目,练习一会儿双拼。这个我预计是不会很耗费精力的

然后周末的时间看整体项目的进展考虑是否要加班,要完成一下对GTD内容的简单总结,可以考虑实践一段时间再总结一次。然后继续推进TIS书的学习。

对于日常运维效率这块,感觉自己应该考虑一个量化的指标,看看运维到底吃了自己多长时间,然后看看是不是可以针对性的提高某些步骤的效率,或者看看有什么可以在新系统的改进意见。
* 这里还有一点额外的,就是简单的时间上的量化对于零碎的运维工作比较难以施行。可以考虑先攒一批运维工作,然后批量的执行,看看整体花费的时间。这样既可以提高效率,也有量化的可能。

项目研发这块,就是上面说的转移重心了。应该考虑启动一些事情,把目前项目中自己掌控力不太好的地方重新研究下。

标签: 暂无
最后更新:2024年4月14日

sheep

think again

点赞
下一篇 >

文章评论

取消回复

COPYRIGHT © 2021 heavensheep.xyz. ALL RIGHTS RESERVED.

THEME KRATOS MADE BY VTROIS