Some of my most rewarding time at work the past 18 months has been organizing and participating in a #peergroup@MongoDB. As part of trying to make that group as good as it can be, I’ve learned some things about running peer groups within a company daviddaly.me/2022/07/peer-g… /1
My current peer group is for #staffengineers#staffplus, but the lessons should apply to many other peer groups within a company. For myself, that has included peer groups for new hires (long ago) and for new engineering managers. /2
When I looked, I was surprised at how few resources and references there were for organizing #peergroups, and especially peer groups within a company. /3
With this blog post, I hope to: 1. Help others organize their own peer groups 2. Demonstrate the value of these groups, and 3. Encourage others to share their learnings with me and other organizers. /4
I’ve also put together a page of resources (daviddaly.me/p/peer-group-r…). I expect to update this page as people share learnings with me and I learn more. /end
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Question for my #performance folks: Any new ideas or insights on getting reproducible performance in the cloud (and AWS in particular)? Specifically on configuring a cloud instance to minimize performance variability /1
My team has spent a lot of effort controlling noise in the past, disabling hyperthreading, using numactl, disabling frequency scaling and sleep states, using placement groups, etc. /2 engineering.mongodb.com/post/reducing-…
I would love to learn more knobs to make things better (lower variation). In particular, we’ve found newer processors and cloud instances to have more performance variation than older ones, and we need to deal with it. /3