2025-01-01 04:54:00
2024 年就这么匆匆的过去,心中感慨万千,这里总结下自己的 2024,规划下 2025 的计划。
这里先写下这个总结,后面我再补充调整。
不停写博客的好处就是,如果你去翻看去年的这个总结,其实开头是一样的,只是改了年份,年年岁岁花相似,岁岁年年人不同。
直接从年初计划 2023总结 并 2024规划 和 2024Q1 总结 那拷贝下任务列表,
这里重新列举下自己的2024计划。
Major tasks:
Accumulating tasks:
2024-12-31 04:54:00
推荐一个网站,感觉非常有用。
HackWay 非常好的自学网站,主要参考了美国的 6 大名校的课程。
说实话,如果不是为了一个 CS 的学位,很多普通大学的课程即使是任课老师也没有这些课程的授课水平,非常推荐大家按照推荐去学习。
当然,这个是文火出慢工,如果面临面试,Leetcode 这些才是你的选择,毕竟 coding 题要是遇到原题,还是非常加分的,这个比较直接,立竿见影。
2024-10-20 23:54:00
最近下前段时间和老板 1:1 的总结,重点是如何正确的估计时间。
SDE 总是要经常估计项目需要多少时间的,这个问题其实很难,原因不复杂,如果这个项目是一个常规的项目,那么大多数时候,计算机的行业经验是把这个任务做成一个服务,然后发布出去。剩下的任务就是按部就班地按照文档操作,调用就行。这种时间估计一般是很靠谱的。
但是如果让你去做一个时间预估,那么这个时候,很大概率是涉及到不少的未知元素,所以大家不知道。那么你的预估其实就是基于你自己的经验去给一个大概的估计,这个准或者不准其实很大概率取决于你的经验和实际的项目难度。
举个例子,你认为数据已经在上游 team 那里准备好了,所以你估计了剩下的 ETL 的时间,但是你真的去做发现,上游 team 并没有把你需要的数据准备好,这个时候就需要和上游 team 沟通,cut ticket 或者开 Sync meetings,这个往往就时间无法控制了。但是你不真正去做这个项目很多时候又很难发现数据又问题。
那么是不是就没有方法去解决了呢?
也不是就没有方法,下面总结下我的一些看法。
你大概心中会有一个时间估计,但是不要直接给出具体的时间。因为往往你给出时间,大家就会认为这个时间是可靠的,即使你强调只是估计。很多时候你给具体时间,大家就会按照着这个时间来评价你的工作,这样你就必须 meet the deadline。但是很多时候很多东西是你无法掌控的,所以永远不要给出具体的时间。
你需要给出这个项目的具体 steps,然后对于每个 step 给出时间 range 的估计。这个 range 有一个比较方便的方法就是, time by 2 and plus 1,如果你觉得这个 step 需要 1 天,你就给 2 ~ 3 天。这样如果你提前完成,大家会非常喜欢和你合作。
很多时候如果你来不及给出 list 或者不清楚,你就说你需要时间来研究并且列出 steps 并且给出估计,然后说 later today or after this meeting,I will send the estimate doc to you 等等。
因为你列出了一系列的步骤,所以你后面也会比较方便找出你的问题,比如按照计划我今天需要拿到上游数据,但是没有,你就可以考虑是不是找对面的 on-call 或者 升级到找对方的上级来解决。
如果出现了很多重大的问题,或者你的 time line 拖的久了,不要自己干着急或者只是抓紧干活,及时 call out 并且找别人帮助。同时有时候这个问题你没办法解决,那就及时 reset time line。
2024-08-30 23:54:00
最近总结写作的风格问题,发现了一点启示,写一篇博客记录一下。
In today’s fast-paced world, effective communication is crucial. To captivate your audience and convey your message with impact, follow these three essential steps:
Time is precious, and your readers’ attention spans are limited. Eliminate unnecessary preambles and dive straight into your main point. By doing so, you’ll:
Writers should ruthlessly edit their introductions, removing any fluff or filler content.
Transform your writing from passive to powerful by replacing descriptive sentences with assertive topic sentences. This approach will:
Editors should review each paragraph, ensuring it begins with a clear, declarative statement that drives the narrative forward.
Don’t leave your readers wondering “So what?” Clearly state who should do what based on the information you’ve provided. This strategy:
Content creators must conclude each section or article with specific, actionable recommendations tailored to their target audience.
By implementing these three steps, writers can transform their content from ordinary to extraordinary, ensuring their message not only reaches but resonates with their intended audience.
2024-08-18 06:54:00
最近买了个柜子,这周六送货上门,结果我没有发现柜子有问题,虽然最后打客服电话还是安排了下次送货。但是还是感觉需要总结下。虽然这是一件小事,但是确实反应了我的一些思维习惯的问题。
很多生活中的小事,给人更大的警醒,需要反思。
这次我有两个柜子,说实话,我怎么细致地思考该检查哪些项目,虽然是一个很简单的事情,但是还是凡事预则立,不预则废。我这次的问题就是柜子的功能没有思考清楚,只关注了下表面划痕,还漏掉了一个柜子检查。可以说,没有想清楚事情该怎么做是我最大的问题。
其实柜子最主要的功能就是抽屉能放东西。我偏偏忘记检查了,一个柜子的螺丝没有拧紧,导致这个抽屉根本抽不出来,这个就是我的最大的问题了。
关注核心功能 First
这次送货上门,我确实是大意了,这个柜子还是配备了充电接口的,结果我其实完全没有检查。说实话,这次是别人服务允许你退换货,所以有一个 backup,但是谁能保证充电接口就能 work 呢?我完全没有检查实在是不应该。换句话说如果出了问题,你还得扯皮实在是不应该。
不要不好意思,我不检查所有的功能我就不签字。不签字你掌握主动,签字了别人送货的才不管你呢,别人直接走路了。
最好的方法,就是让他们等着,给我 5 min,我要检查下,不然我不签字。
这次退货的那个柜子,其实我就发现了不对,第一包装袋不完整掉下来了,第二一个接口有松动。这个时候,就应该告诉送货的,我需要更多时间检查,而不是别人说没问题你就认为没问题。他一个送货的,说实话才不管你是不是好用。
这次之所以换货,就是我发现另外一个柜子那个部件是固定的,而不是松动的。所以坚决要求退货。但是,在送货还在的时候,我没有反应过来,错过了指出的机会,其实就应该和另外的一个产品对比。这样即使你不是专家也能分辨出问题。
当然,如果没有对照的话,那就还是要明确核心功能,一样样检查,不检查完,我不签字。不要不好意思,这次我至少打了半小时电话才解决问题,如果当场指出,说实话,十分钟就能解决。
核心总结,明确核心功能,一件件检查。
说实话,我也知道这个是一件小事,但是却是给我的警示,说明我在处理问题的不完善,无准备,容易被人反客为主,很多时候完全可以让人等一等。明确好以我为主的思想。
2024-08-11 06:54:00
工作中经常要用 AWS,有些时候虽然云带来了生产力的解放,但是还是有很多特属于 AWS 的小知识点,这个帖子记录下来。如果有新的体会我也会不断总结到这个帖子。
为了安全,AWS 所有的操作都需要相对的权限,当然这个错误比较好 debug,一般都会报错,XX 账号/ IAM Role 没有操作某某的权限。
这个有时候会忘记。
AWS 为了服务的快捷性和安全性,是分区域的,所有有的时候会出现你没设置对区域从而找不到对应的服务和设备。这个是不太容易 debug 的,因为从 code 角度你设置的是对的,代码也编译了,只是不在同一个 region。
有时候,代码编译突然通不过了,或者出了很多奇奇怪怪的错误,但是你们组的别的组员都没有问题,那就很有可能是 workspace 出了问题。这个时候清空 workspace 是最好的选择,从头开始,往往很多问题也就解决了。