本文由Markdown语法编辑器编辑完成。
1. 前言:
不知不觉中,我从研究生毕业实习(2013年2月)工作到现在(2022年1月),已经有8年多的时间了。
在过去八年的职业生涯中,我共经历了两家公司。一家是国企控股的民营企业,工作了5年;另一家是目前就职的公司,是一家成立五年多的医疗影像AI创业公司。
在过去八年的职业生涯中,由于不同项目的需要,学习了C++, Java, JavaScript, Python这几种主流的编程语言;学习了Oracle, MySQL两种数据库技术和SQL;使用了Visual Studio, Eclipse, Pycharm, VSCode, Sublime, Notepad++, Vim等或复杂或简单的IDE;学习了医学影像DICOM的相关知识等等。
大大小小的项目也经历了许多。最长的几个项目,都持续了一年到两年之久。在上一个公司的最后一个项目——门诊HIS系统,直接整个项目组都驻扎在一所医院的几个空闲出来的办公室,项目组招聘的笔试和面试,都是直接在医院现场进行。在做HIS的药房药库模块时,每个月底,我都要去和医院药房药库的老师一起盘点当月的收入和支出情况,如果出现数字对不上的情况,还需要连夜进行数据整理等。有时候半夜还要跑去急诊科室,给医生解释为什么用我们的系统,没办法开出药来等等。
所幸这些项目都熬过来了。再难的项目,加上时间这个维度,都会一一解决。回过头来看,会觉得也许并没有当初想得那么难。就像我们公司的CEO曾经说的,每一年结束时回顾过去,我们都跨越了前一年看起来非常非常难的障碍。而且曾经有一句话是,如果你感觉累,说明你走的是上坡路。
由于参加工作时已经27岁了,因此工作8年后,我已经35岁了。不得不说,焦虑已经随之而来。面对着项目组越来越年轻的同事(现在最小的同事,比我小11岁),我必须思考自己工作这么多年的价值在哪里。我需要如何才能找到自己的核心竞争力,而不至于变成边缘人,甚至被淘汰的命运。
2021年12月31日晚上8:30, 我又和往年一样,早早地就准备听罗振宇老师的跨年演讲。这是罗振宇老师自承诺要连续举办20年跨年演讲的第7年。只不过今年的跨年演讲和往年略有不同——往年的跨年演讲,台下都坐满了几万名观众;而今年由于成都的疫情防控政策,台下只有一位和罗振宇老师配合的音乐导演,其他座位上,则摆满了他们从大街小巷买来的,形态各异的1000只大熊猫玩偶来烘托气氛。
罗振宇老师今年的演讲,基本上是在讲各种各样的小故事,数量是53个。通过这53个小故事,将相应的观点抛出来。
我于是也想借鉴罗老师的跨年演讲的方法,通过讲故事的方式,来进行一下今年的工作总结。
2. 2021年个人工作总结:
2.1 OKR vs KPI
OKR, 是Objectives + Key Results的三个单词的首字母缩写,是现代企业的一种新型的管理和绩效评估方法,它和KPI是不完全相同的。尽管公司高层对于OKR是非常重视的,专门请了外部的培训师,给高层和各级管理者进行了OKR的培训。公司内部的晨会,也多次提到了公司的管理,要逐步以OKR为导向。
年初时,我们各个部门都制定了当年的年度OKR。OKR, 分公司级别的OKR, 部门级别的OKR, 每个员工的OKR. 原则上,各个部门的OKR中的O, 对应着公司级别OKR中的某一条KR; 部门员工的O, 对应着该部门的某一条KR. 这样,就做到了一个目标的上下对齐。
即每一个员工的目标,是为了达到该部门,承诺公司为了实现一个公司级别的目标,而列出的关键结果中的某一个结果。
关键结果如何衡量是否完成,是一件比较困难的事情。这首先要求关键结果,需要尽量给出一些定量的指标。比如性能提升20%; 端到端执行时间控制在xx秒内;每千行代码的bug控制在xx内,…
尽管年初时,部门的确付出了很大的精力来制定和拉齐OKR. 但是,对于工作节奏较快的公司来说,感觉确实很难真正用好OKR. 考核时也很难依靠OKR的完成度来进行评估。
理想和现实,还是存在一定的差距。
2.2 茶话会(困在数字化系统里)
4月初,研发部迎来了第二次茶话会。这次我毛遂自荐,准备了做报告。
这也是我进入公司两年多后,第一次在研发部的全体成员前发言,还是比较紧张的。那段时间同时也在学习吴军老师的《阅读与写作》课程,其中有两节课程是关于如何做好公众演讲的。我仔细学习了好几遍,领悟到了公众演讲的精髓,一个是充分准备,多次演练;另外一个是观点鲜明,只讲重点,站在观众的角度思考。
在去年的博客中,曾经写过一篇关于当时如何准备这个报告的心理过程,这里不再赘述。想说明的一点是,当时我正在和同事做一个预警系统的开发。这个预警系统,能够实时监控线上运行的各个服务的状况,如果发现服务异常,就会自动地创建工单,并且报告给相应地负责人。可以说,这个监控系统,将很多原来需要人为干预的很多操作都自动化了,可以为公司节省很多的人力成本。
我当时在想,我开发的这个预警系统,会不会让很多一线的执行同事失业呢。人物公众号在去年发布了一篇《外卖骑手,困在系统里》的文章;而当年的跨年演讲,罗振宇老师则将“困在数字化系统里”的涉及范围扩大了,不光是外卖骑手,办公室白领,K12教育等等,都困在了数字化系统里。
那么如何破解这个困局呢?罗振宇老师最后给出的答复是,“有的人,就是会被困在数字化系统里,甚至会被系统替换掉;而有的人,则会因为数字化系统而变得强大。数字化系统对你来说是蜜糖还是毒药,只取决于你是对人负责,还是对事负责。”
于是,我在茶话会的最后,将这个概念抛了出来,将罗振宇老师的这一番话抛了出来,也是希望呼吁大家,在平时的工作中,也要更注重对人负责,对客户负责,而不仅仅是对事情负责。这样,我们才能充分地发挥主观能动性,形成自己地独特的竞争优势,而不至于被数字化系统所替代。
2021年罗振宇跨年演讲3: 谁能跳出数字化系统困境?
2.3 喜迎CTO
在经过了大半年的空档期后,公司又聘请了一位医疗行业内的前辈,来公司担任CTO。
与以往偏重于管理的CTO稍有不同,新任CTO本身对于医疗影像有很深的造诣,对于医疗影像AI也有自己独特的见解。
在就职演讲时,就给研发部的同事们讲了很多他的管理特点,对于技术人员的成长期待和规划。讲到了“T”字型人才培养战略。
而在讲到关于AI产品的研发状况时,新人CTO提到了,希望能够在短时间内,研发出很多产品,然后一股脑儿地都推给一线医生,希望能够在众多的产品中,脱颖而出一些爆款产品。
众所周知,医学影像,由于其本身具有的三维特性,因此在进行处理时,需要依赖很多线性代数的算法,无形中提升了算法开发的难度,也使得现有产品线的迭代速度放缓,且新增产品线的开发周期较长。
新任CTO结合自己在医疗领域的深耕,为我们指明了一些未来可以发力和重点研发的方向,让我们对于未来充满了期待。但是,有这么一位业内资深的CTO带领,大家的心理都比较放心,也让我们看到了CTO的价值所在。
希望每一个搞技术的人士,都能朝着CTO的方向努力。在完成当下工作的同时,多思考,多锻炼,多分享,多讨论,成为一个全面发展的技术人。
2.4 工作重心发生转移
在CTO的倡导下,我的工作重心发生了一定的转移,逐步向自己更熟悉的图像处理领域靠近。
在一开始,我们成立了两个人的小组,开始进行一些前期的技术探索。
探索的过程,遇到了很多未知的难题。如果是过去,可能就会想办法去逃避这些难题。但是,由于这是CTO主导的项目,是受很大关注的项目。因此,我们也只能迎难而上,遇到不懂的问题,就去网络上请教相关的技术大神。在大神的指引下,一步一步地进行技术的解锁和跨越。
在经过了一个多月的探索后,我们终于摸出了一些门道,解决了一些工程化的难题。将一个理论上可行的项目,变成了一个可以工程化的项目。
这也极大地提升了我们地自信心,对于贯彻CTO的技术路线,也起到了很大的推动作用。
这时,我又想到了我刚参加工作时,我的第一位大领导给我的忠告,遇到困难时不要灰心,要尽可能地去搜索解决思路。然后给了我一个反问,难道你觉得你现在遇到的难题,是世界上第一个遇到这个难题的人吗。如果不是,那么你就一定要对自己充满信心,别人能够克服的,你也一定要努力去克服。这句提醒,也一直鼓舞着我,遇到问题不退缩,而是迎难而上。
2.5 校企交流会
我们公司,目前我知道的,和我来自同一所大学的有5位同事,涉及到三个学院,计算机学院,生命科学学院,艺术设计学院。其中和我来自同一学院的师兄,是做市场营销方面的工作,所以他会经常与外面的机构打交道。公司和高校之间也经常会有合作交流。
某一日突然收到师兄的留言,说是7月下旬,我们学院的老师会带领一个实验室的同学,以及大四的同学们来公司交流,邀请我代表技术人员,给老师和同学们分享一下自己的成长经历等等。
我当时非常的兴奋。想想自己,不知不觉研究生也已经毕业八年了。从毕业后到现在,回学校的次数不到5次。而这次竟然是学院的老师和同学们来参观我们公司。我觉得这样的交流会,对于学校和公司都是双赢的。
对于学校,学院,老师和同学们,能够了解到专业在公司中的应用,对于学生们更好地选择未来的职业提供了一些案例;而对于公司,通过和学校老师们的合作,可以提前吸收一些优秀的学生来公司实习,为公司储备技术人才,也可以和学校联合申请一些科研基金等。
在校企交流会的那天,见到了自己曾经的几位老师,非常的开心。当我站在讲台前分享时,看到曾经的老师在下面对我微笑,我心里很温暖。我也把自己的一些经历分享给大家,同时说出了自己的几点感受:
1)大家一定要珍惜在校的时光。首先在学校的时间,可以不用操心吃穿住的问题,大家可以安心用来学习和搞科研。工作以后,会有很多精力分摊在别的事情上。其次,学校有很好的资源。图书馆,自习室,实验室,这都是非常好的学习环境。现在在北京,上海等大城市都有很多的付费自习室,供很多毕业后想要充电的人们,继续学习。或者考证之类的需求。还有,阅读论文。学校有知网,但外面可能就要付费下载了。
2)希望大家养成善于积累总结的习惯。平时学习和科研,能够多做一些笔记,多写一些文档。这样在有新同学来的时候,可以很快地让对方上手。程序员最怕两件事:写文档;别人不写文档。九层之台,起于垒土。不积跬步无以至千里。我们在学习中一定要注重积累。不管是平时学习,科研,阅读论文,思路,想法,都可以积累起来。既可以帮助自己整理,同时也便于日后给师弟师妹们看,能够更快地上手操作。科研,最重要的就是重复性。就是,你做出一个成果来,如何让别人能够认可呢?那就是,如果别人按照你的步骤,能够复现这个成果。如果只有你自己能做出来,别人却无法重现,就会怀疑你的成果的可信度。
3)要注重英语的重要性。英语,至少在程序员的工作中是非常重要的一个技能。小到,如何定义一个变量和函数的名字,大到解决编程的问题时,都是需要查询外国文档的。或者是外国的开源社区,开源项目。
4)既要做科研,同时也要关注这个世界的变化。AI就是最近这几年火起来的。xxxx,今年已经五年多的历史了。五年前,AI+医疗,还是一个非常陌生的领域。但是,在CEO的带领下,国内出现了很多很多的AI+医疗公司,医疗行业也是未来的一个朝阳产业。AI+各个行业,可以有很多很多的创新。大众创业,万众创新,希望大家能够在学校夯实自己,厚积薄发。同时,也希望大家能养成终身学习的习惯。
分享会结束后,师兄带领老师和同学们到了公司的荣誉室,看了看公司研发的几个产品,以及荣获的很多荣誉。我也听老师们说,现在学校的孩子们也都很厉害,在校期间也在积极地学习人工智能,参加很多的竞赛,积攒了很多的经验。
2.6 困扰一个月的难题终于解决了
随着工作重心的转移,很快便遇到了难题。由于在图像处理方面,我可能还是稍微比较有经验的,于是攻克这个难题的重任就压在了我的身上。那段时间,我觉得自己才真正地进入了状态,全身心地投入到了攻克难关的战斗中。在网上搜寻着一切有可能的解决方案,甚至我都被逼着用蹩脚的英语,在相关的论坛上请教全世界的前辈们,希望能够得到他们的指导。
由于时区的差异,每次我白天在论坛上留下的问题,至少要到第二天才能得到对方的答复。那段时间,只要我前一天下午或晚上留了言,第二天一到单位我就先看论坛是否收到了回复。每次收到的回复,都非常的有参考价值。
最终在一些技术前辈们的指导下,以及自己不懈的尝试下,困扰了一个月的难题终于得到了解决。但是这时问题也只是得到了初步解决。整个程序还是不太稳定,每次给别人试用的时候,我都提心吊胆。后来我想到,我不可能去实际控制真正的客户怎么去用我开发的功能,而是应该尽可能地使自己的程序更加鲁棒。
2.7 开始尝试带新人
不知不觉中,来公司也已经三年多了。在互联网公司,能呆三年也算是老员工了。今年随着我们部门又招聘了一些新人,我也被安排了带新人的任务。在前几年的工作经历中,也曾经带过一些新人。我觉得带新人,对于新人来说,是一个考验,对于导师(公司内一般带新人的称为导师)而言,同样也是考验。这个考验是,如何平衡自己手头的工作时间和带新人时花费的时间。
带领新人,对于导师而言,在前期来看,可能是投入产出比比较小的,因为你需要把自己已经很熟悉的内容,再给新人讲出来。你以为很简单的内容,对于新人来说却十分的陌生。有时候接到一个任务,如果自己来做,可能10分钟就做完了,但是如果交给新人来做,可能就会花上大半天,甚至更长的时间。这个时候,一定要控制住自己,不能插手太多。因为自己虽然能在短时间内完成,对于自己来说,可能提升有限。但是对于新人来说,这可能是一个全新的挑战,他要去学习很多基础和业务知识,了解很多背景,和很多同事进行沟通,才能够完成这一个任务。那么对于他未来的工作,提升就是非常明显的。
这时候,我就想到了2021年的热播剧——《功勋-李延年篇》中,李延年对五班长韩东年说的一句话,“尊重和信任也是战斗力。” 你只有尊重和信任新人,给予他们必要的指导,才能将他们的能力和潜力发挥出来。如果什么事情都亲历亲为,什么事情都大包大揽,自己可能累得半死,对于整个团队的贡献,也无法发挥出1+1>2的效果。
在带新人的过程中,自己也会发现很多过去似是而非的东西,当自己讲不清楚时,说明自己可能也没有完全理解清楚这个知识点。那么对于自己,也是一次学习和提高的机会。在带人的过程中,我觉得知识的传承非常的重要。这时候写作的习惯和能力就发挥出来了。如果你事先在完成很多任务后,能够及时地总结,并且将它们写在wiki中,那么日后当你交接这部分工作,或者是给别人讲述时,就可以把之前写的wiki发给他们,这样就大大地节省了沟通时间。而且,写作只需要耗费一次的时间,但是以后就可以给很多很多的人看了,真的是一个事半功倍的事情。这也是我为什么喜欢写wiki和博客的原因。
希望大家也能够养成完成一个任务,就及时总结的习惯。所谓”温故而知新,可以为师矣。”
2.8 性能优化,是吹毛求疵,还是刻不容缓
今年下半年,接触了一个项目。项目的开发大概花了一个多月的时间,主要是把之前的一个B/S架构的项目,用C/S架构实现一下,同时新增一些额外的需求。项目的功能,在预期内基本完成了。本来以为基本可以交差了。但是当产品真正安装到医院医生的电脑上时,各种问题才接踵而至。后来随着产品经理亲自带着研发,去医院搜集前线医生的使用反馈,我们才意识到,医生关心的和我们研发关心的,可能并不是一回事。
研发关心的,可能是某个功能是否做到了完美,需求里面的功能点是否都覆盖了。但是,作为用户的医生,他们关心的可能是,我首屏加载时间是否够快,切换不同病例数据时是否够快,程序是否稳定等等。对于具体的功能,他们虽然也会关心,但绝对不是最重要的。
其实换个角度思考一下,医生为什么要使用一个新的软件呢?他当然是希望提高工作效率的。如果这个软件没办法做到快速打开,快速切换,那么无论这个软件的功能多么酷炫,他的使用体验都不会很高。
因此,当产品经理在和医生沟通后,给我们列出需要改进的列表里,改善性能便是优先级最高最高的,高过任何功能的bug。这个时候,你就不能说性能优化是吹毛求疵了,而是刻不容缓,重中之重了。
那段时间,为了优化性能,我们查了很多资料,自己地把代码又review了几遍,找到所有有可能托慢性能的地方。为了优化首屏加载性能,试了几个不同的方案,将一些加载项从默认加载变成使用时再加载。经过大概1~2周的优化,终于将首屏加载时间,从60s左右压缩到了15s甚至更短,这才勉强满足了医生的使用要求。
性能优化,作为软件开发生命周期比较靠后的阶段,往往会花费超出预期的时间和精力。如何改善这种状况,避免在交付软件后再急匆匆地优化。我想,在开发的前期,可能就要想到哪些操作,是比较耗性能的,提前想好一些预案,或者在流程设计时进行优化。
2.9 面试别人比自己工作难多了
在找工作时,经历了很多次面试,参加过的绝大多数面试都以失败告终。第一个面试成功,且给我offer的企业,也是我毕业后第一份工作所在的企业。后来我也就没怎么参加过面试了。所以我其实比较羡慕那种一个人拿七八个offer的大牛。后来在换第二份工作时,也是就参加了一次现场面试和电话面试,就换到了现在的企业。不管是参加哪家企业的面试,我在面试前都会比较紧张,为了缓解紧张,我也会准备很多很多的资料,也会查询一些面试企业的基本情况。
参加工作后,我作为面试官,单独或参与面试,大概有十余位应聘者吧。在面试之前,我一般都会仔细地阅读应聘者的简历。
应届生由于还未工作过,主要看的是毕业的学校,专业,主要课程,学分,毕业设计和参加过的各种实习和竞赛。社会招聘的,则会更加关注从毕业开始,到现在的一个工作经历。
其实从简历中看,很难有各种条件都完全契合的。毕竟学校专业那么多,每个公司的业务也差别很大。你很难要求,从外面很快就能找到一个背景十分吻合的应聘者。因此,面试其实是一个取舍的过程,就是在很多的比较项中,你更关注和在意的是那几项。通过比较和权衡,得到一个相对值。
面试有时候还跟面试官个人喜好有关。有的面试官看重算法,有的可能看重项目实践,还有很多方方面面。有时候面试也是一个挺随缘的事情。有的时候,我正在工作中,突然领导发给我一封简历,说半个小时有个面试,和我一起面一下。我就只能赶紧把手头的工作放下,仔细地看对方的简历。有时候应聘者提到的技术自己也不懂。记得有一次是一位北邮的应届生,她的毕业设计提到了”预测执行的计算机体系结构”。我看了好几遍,都不明白这是个什么技术。于是我赶紧google,把排在前面两篇相关的文章都读了一下,才知道了这个技术的背景。
看来面试,不仅是对应聘者的考研,对于面试官来说,也需要你在短时间内,快速地学习和了解简历中提到的一些技术,才能避免你在面试别人的时候显得业余。
另外我面试别人时,比较看重对方的态度。有一次面试一位应聘者,我问他对我们公司的业务有什么了解时。他却完全不知道。我其实还是蛮惊讶的。既然你面试想进入一家公司,但是你来面试前,却连这家公司在做什么都完全不知道。最起码查一下公司的官网就可以了解的内容他却没有。我当时内心就觉得很失望了。接下来如果没有特别优秀的表现,基本上就被pass掉了。
而且正如领导跟我说的,不管对方简历上写得多么全面和丰富,你都不能全信。用领导的话说,就是要去验一验。也就是说,面试官会带着一种怀疑的心态去询问对方,来验证简历上的内容,到底可信度有多高。面试官面试也是担着责任的,万一面试的时候没有把好关,把不合格的人招进来,接下来其实会比较麻烦的。
所以,应聘者有诸如《面试宝典》之类的参考,作为面试官,也是需要修炼的。只有更充分的准备,才能得到更好的结果。
2.10 负责一个小项目的迭代
一个项目,如果自己的负责人,和自己是一个项目成员,感受是完全不同的。
在之前我更多的是作为项目成员,开发一些核心功能模块。这时,只要自己把承诺的那部分工作完成就基本ok了。但是,如果你是负责人,你显示不能满足于此。你需要承担更多的,沟通和协调的工作。这时,你不仅要思考功能如何实现,还需要考虑如何分配人员,如何把握项目进度,如何跟产品经理博弈等等。
今年最后两个多月,我负责一个项目的新一期迭代开发。项目组成员在5人左右,初始预估是需要33MD左右。由于部分项目组成员同时还肩负着别的项目的开发或后期维护,所以其实一个人一天真正投入在这个项目的时间是无法确定的。虽然实现可以给予一个0~1之间的比例来估算,但是每天由于需要处理一些线上的问题,问题可大可小,处理起来难易不同,占用的时间也不同。因此,其实每个人每天的投入是一个动态变化的。那么如何能够准确地把握这个进度呢。
我后来想到了数字化。就是将一切的,难以衡量的指标,都尽量的数字化。统计单位按天计算。统计每个人每天实际投入的时间比例。然后每天下午开完站会后,将每个成员报的投入记录下来。横向相加,是当天项目组的有效投入;纵向相加,是这个人在这个项目中的累计投入。给大家一个示意图:
通过这样详细的记录,我们就可以随时看到项目目前的进展状况。在项目后期复盘的时候,也可以了解项目的实际用时和预估用时的差异,每个人对于项目的时间投入和贡献占比。
我想这也算是一种数字化吧。正如罗振宇先生在2022年的跨年演讲中提到的数字化。他最后的一句话是说,大企业有大企业的数字化,小企业也有小企业的数字化。
除了数字化记录外,在每天的站会中还邀请了产品经理来参加。事后看来,这是一个非常正确的决定。因为我发现,软件开发人员为了严谨,在做一个需求时,会想到各种可能的情况。但这些情况,在初期估计时间的时候一般想不到。但是为了编程时覆盖这些情况,实际有可能耗费两倍甚至更长的时间,这会给整个项目带来一定的风险。
这个时候,通过站会时和产品经理说明问题以及风险,产品经理根据她的经验,通常会对需求做一些细微调整,尽量规避掉一些不太可能发生的case,这样对于开发人员,就节省了很多宝贵的时间。
所以我觉得充分的沟通交流,发现问题及时提出和解决,都是很重要的。
2.11 把学习当作习惯,水滴石穿,勤能补拙
在一次和同事的聊天中,同事抱怨说,现在工作太忙了,都没有时间学习了。这从一个角度说明,工作和学习是两回事。工作更多是一种输出,而学习也是一种输入。
就比如阅读和写作。阅读是输入,写作是输出。如果没有持续地阅读,那么写作也就无从谈起。正如诗中说到,“问渠那得清如许,为有源头活水来。”
在刚参加工作时,我的直属领导找我谈话时,说我不是特别聪明,因此需要加倍努力工作。
领导的评价对于一个人的影响往往是很深的。也许从那时起,我就暗暗告诉自己,我不很聪明,所以我必须付出比常人更多的时间学习,才可能不被淘汰。于是在工作后,我依然在不断地学习。
但学习毕竟是一种反人类天性的行为,如果只是凭借自己的高度自律逼迫自己学习,那学习就像是一根紧绷的绳子,时刻面临断掉的风险。
有没有什么方法,是能让学习不那么耗费精力,变成一种习惯呢。我想利用正反馈是很重要的一点。为什么游戏那么地吸引人呢?就是因为游戏中的画面和音效,都是对于玩家操作的一种反馈,时不时跳出的金币,积分,道具,装备,等级等等。
罗振宇老师曾经在一次分享中提到,如何戒除网络游戏呢?他曾经试了很多办法都不太奏效。后来请教一位游戏公司的产品经理,给出的办法是玩游戏时摘下耳机。果然,在失去了游戏里面动感的音效刺激反馈后,游戏的吸引力顿时下降很多。这便是利用减小一些正反馈的回路来降低游戏吸引力的解决方案。
对于学习,我们则可以通过增强正反馈来激励和帮助自己形成习惯。
比如写博客这件事情,其实就是一个反馈。首先通过自己的学习和思考,把自己工作中的问题和解决方案记录下来。当发布到博客后,就会有更多的机会被同行看到。他们的阅读,评论,点赞和收藏,这些都是针对你这篇博客的正反馈。此外,博客平台还会每周帮你统计好每周的博文总阅读量,单篇文章阅读量,总评论数,总收藏数等,还会以柱状图,曲线图等多种方式展现出来。这既是博客平台本身增加用户粘性的方法,但也是给每个博主的反馈。
除了写博客,在公司内部定时分享,帮助同事解决问题,参加讨论时多问好问题,诸如此类,都是反馈。
上一篇博文中写到我在11月底通过腾讯会议,给母校生命学院大一新生做关于生物医学工程的报告。在准备报告的那一个月里,我在地铁和回家后,都在看耶鲁大学生物医学公开课,早上6点多起来做ppt约一个小时。虽然最后正式报告只有1.5小时,但是背后却是我一个月的准备和思考。
感谢那次报告的机会,让我好像又回到了大学期末和考研那段时间,拼命学习的状态。但学习不能靠突击,还是要靠日复一日的坚持才可以。
2.12 避免成为公司定制化人才
未完待续…
版权声明:本文为博主作者:inter_peng原创文章,版权归属原作者,如果侵权,请联系我们删除!
原文链接:https://blog.csdn.net/inter_peng/article/details/122266741