你们团队有实现常态化、有营养的定期技术分享吗？

听很多朋友说，他们那的技术分析，搞成形式主义了。
把很多几分钟能看完的技术博客，洗稿成一两个小时的技术分享，纯纯浪费时间了。

发起人也没起带头分享作用，直接导致整个分享机制走向形式化，

我们之前有,后来没怎么有人分享, 就半死不活了, 差不多 有一年没搞了把

现在网络太发达了，技术分享没卵用，知道有个名字不够，你得跟竞品 ABCD 在特定场景下讲出 1234 来还得有填坑的能力

说白了，你负责引入新技术，那你能帮忙填坑么

我的看法，大家追求不一样，水平不一样，侧重点不一样。
再加上这种东西本身就看时机看机缘，谁也不能保证稳定输出高质量的内容和想法。
如果把这个当成一个定性要求去看，又要质量又要定期，死是应该的。

我们都是在 confluence 上更新学习笔记，开会太浪费时间了

能分享干活的人，1%
所以不要分享干活

最他妈烦让我调研完了分享，分享你妈啊复制粘贴过来重复一遍懂得不想听不懂的还是不懂不如自己看省时间

以前有，就大概半小时，讲一个技术点就行了

有分享，晋升的必要条件。但是我们只是走个形式。分享内容一言难尽

我们有过很有意思的内部分享（六七人的 SRE 小团队），不过常态化这一点，没做得那么稳当，有时候大家忙或者没人报名也会推迟或取消。
大部分都是从工作出发寻找好的内容来分享，当然也有跟工作关系不大的分享来自同事们的个人兴趣爱好。

大概来说，以前我们分享过的有：一些 AWS 服务的特殊用法、go 语言的性能问题分析与优化、kafka 的架构与运维调优、数字证书与 TLS 协议的细节以及在工作中相关的应用点、NAT 网关与 NAT 穿越、如何对一个数十万 QPS 的 nginx 网关做现代化改造、如何将一个承载数十万 QPS 的 K8s 集群升级到新版本，聊一聊 MySQL 的一条 SQL 是如何执行的、公司监控系统的演进、Envoy 的使用，等等。

总体感觉还是挺有营养的。

不要搞成轮换制，搞成投稿制，固定时间周期 check 一下大家有没有投稿，提供个窗口就行了。不是每个人都有货，也不是一直都有货。时不时分享些有意思的玩意儿能提高团队积极性，技术氛围还是很重要的。

可以搞自愿分享，，然后根据质量奖励现金

轮流分享，还没完成一轮，就逐渐瓦解了

组里没有，tech talk 费力不讨好
org 的 brownbag 倒是每周都有至少一次，但是每次都是在午饭时间，懒得去…

我们是有常态但没营养，主打一个聊天放松。
既要有常态又要有营养，那肯定搞不下去，做分享的累、听分享的也累。

每个周的 code review+每个月的技术分享(培训)会,例如今天就讲了《重构：改善既有代码的设计》

轮流分享，一周一位，现在感觉成负担了

感觉常态化和有营养互斥了。

@lincanbin 我们团队之前有挺不错的分享，领导也懂技术，而后换了领导之后这个新领导不懂技术，机械的让我们每周组织一次技术分享，导致大家都没啥兴致了，后来又换领导就取消了

@yleoer 我们之前不定期，后来一周一次大家也没有那种激情了

没有，业务都写不完，分享个

定期分享，过不了多久你就会发现，市面上的中间件/数据库/操作系统都被讲个遍

以前有，每周分享，不过疫情后就没继续了。

@ryan4yin 对老哥分享的这些主题还蛮感兴趣的，有公开的资料可以看看嘛？

技术分享本身是没问题的，但是仅限大厂，一个团队上百人，轮一次至少一年，这样的分享在有积累的情况下才会言之有物，小厂才几十甚至几个人，时间频次太短，非常容易假大空，讲多了就没什么讲的了

@nixum #24 是纯内部分享，没有公开资料。不过我自己分享过一些议题（数字证书与 TLS 协议、NAT 网关与 NAT 穿越）是来自我的博客文章，你可以上我博客翻一翻。

与其内部分享 倒不如自己写博客总结 一次好的分享总是要花很多时间总结