2
Sharing
今天安排了一位资深的Linux C/C++ 的同事为大家做了一次分享,主要将程序运行时在系统底层究竟是什么样子,可惜的是我今天没能参加,不知道效果如何。
这里说说我对“培训”的看法,其实我喜欢叫它“分享”,这样可以降低讲授者的压力。每周我们会安排30-60分钟的时间,请一些同事分享最近对某些技术的心得,目的是大家共同提高,共同进步,培养分享的氛围(我曾经做过一次,专门聊分享的重要性)。在经历了一段时间的实践,我们发现一些问题,虽然也有成功案例,但大多分享很难提起大家的兴趣,台上照本宣科,台下昏昏欲睡——WHY?
** 授人以渔 **
分享,要彻底,毫无保留。不要传授结论,要传授方法。比如,我们做一次Case Study,某网络服务挂掉了,我们用1天的时间解决了,然后我们告诉大家,是因为多进程并发时,某个逻辑中产生了死锁,大家要以后要注意。我想这时一半人已经睡了,我如果知道问题是什么,再弱的人Google 一下也知道如何解决了,分享的意义何在?可悲的是,我们大多数的分享都是这类的。其实,大家更希望了解你是如何发现问题的,你思考的过程,他消化后没准还能举一反三,这才是分享的价值所在。
另一方面,分享不一定把某个问题讲清楚,也许给大家留下一些谜题更有价值。比如之前我们曾做过一次二进制文件的布式存储和分析系统的设计分享,那只是个概念草稿,甚至最终也没有实施,过程中我们聊了,如何给这个问题定性,为什么不使用Hadoop,为什么使用一致性哈希算法,架构为什么设计成这样,等等。大家都在认真的听、思考,并提出了很多问题。虽然这次分享没有什么立竿见影的效果,但不久后,我发现大家在各自架构演进中,都有意无意的引入了一些这次分享中的概念,我想那时埋下的种子——发芽了。
最后:分享,收获>付出。
什么风格无所谓,重要的是要吸引听众。非常同意,分享的收获>付出,甚至我觉得根本谈不上“付出”
btw:以后有分享提前通知哈~
No problem. Thanks =)