Writings

A place to place some writings

重新思考技术分享

最近的一次技术分享

最近我搞明白了一个困扰我们很久的内存回收的问题,欣喜之际,我打算在组内分享一下我对这个问题的最新理解,并借此机会分享一下内核内存管理的基本知识。

于是我花了半天时间做了个非常粗略的 PPT,然后在组内做了这次分享,但分享的效果可以说是很差。

下来后我反思了一下,原因大概有这么几点:

一、企图在短时间内分享很多内容。

这次分享,我准备了物理内存管理、Cgroup v1 的原理、内存统计、内存回收等内容。要在短短的一个小时里把这些东西都讲清楚基本上是不太可能的。另外,内容越多,涉及到的细节也就越多,分享也就越容易失控。

二、没有考虑到所讲内容和听众的接受程度。

组内的同学对内核内存管理方面基本上没有什么了解,大部分人甚至都没有听说过“slab”。在这个前提下,如果还要强行分享内核内存管理的相关概念以及甚至是一些实现细节,那肯定如同听天书。

果然,分享结束后,组里的同学打趣道:“刚开始尝试理解你说的东西,但是很快就跟不上了,就放弃挣扎了。”

在不同场合、不同受众,分享的内容应该是不一样的,这样的内容放到某个内核爱好者会议上去讲,那我觉得应该就不错。

三、自己准备得不够充分。

理查德·费曼说过:“if you can’t explain a theory in a simple way understandable to kids, then you didn’t understand it well.”

也就是说,如果你不能把一个理论讲清楚,那么就说明你还不够理解。

一方面,我自己对我要分享的内容并不够充分的理解,另外一方面,演讲的内容也准备地不够充分,PPT 也都是当天制作的,也没有打好腹稿。

准备不够充分,也就导致分享非常不顺畅,频繁出现卡壳。

改进措施

以后再做类似的技术分享,应该按照如下的方式来做准备:

一、如果是内容很多的分享,尽量写下来,通过文档的方式来分享,而不是通过用嘴巴说的方式来分享。道理很简单,一个复杂的问题是很难通过嘴巴来描述清楚的。

二、每次做技术分享,应该只分享一个相对较小的主题。可以是最近遇到的一个问题、可以是某个工具的使用、可以是最近看到的……如果能把这个相对较小主题给讲清楚,那这次技术分享就算成功了。不求大而全,求精而细。

三、内容应该契合听众的接受度。

四、可以围绕要分享的主题准备一些故事或者段子,在讲的时候穿插着抛出这些故事和段子,让枯燥的技术分享多一点趣味。这是我从一个前辈那里学到的,有奇效。

最后,当然是多锻炼演讲的能力。我们工作性质的原因,大部分时间都是一个人对着电脑,和他人交流也都是在线聊天或者写文档,很少有面向多人做严肃演讲的机会,所以这方面的能力很自然就是欠缺的。没有办法,只能多创造演讲机会,多锻炼。