[khalilravanna]

Mine is actually very similar to OP’s! I think regular discussion of code is such an impactful tool in an engineering organization.

I think as a manager it’s often the small things that can have the biggest impact. At my current company I helped revive a meeting we have called Code Read. It’s basically a meeting where the engineers sit down and go over the commits from the last couple of days focusing on ones that implement something novel or are a good learning opportunity for other devs. Sometimes it’s as simple as “what’s DRY” or “what’s a decorator” and other times it’s a deeper discussion like the performance impact of switching to immutable data structures.

It’s been especially impactful because I also pushed for us to hire some junior engineers and it’s been a wonderful way for them to get exposed to a lot of great lessons and feedback outside of the PRs they already have. Since then, those engineers have all come into their own and some of them are becoming heavy hitters.

[zaphod4prez]

I would LOVE to hear a little more about this & anything you've learned about making these meetings effective. Would love to know how long do they last, how many ppl are in the meeting usually (wondering what the "right size" is), or if you got that idea from somewhere?

[khalilravanna]

Where the idea came from: one of our engineers Will Seitz suggested it. I'm not 100% sure where he got it from. I absolutely love it though and have been a big proponent since the first one.

How long do they last: 30 minutes on Tuesdays and Thursday

How many people: 4 when we started, up to like 10-12 now. I think the right size is like 6-8 maybe. We're approaching critical mass where we either need to add a lot of process or splinter it into separate groups with a good ratio of experienced to less-experienced people.

General musings: We have a separate one for the frontend and the backend each. We started with the frontend one and that's the one I've run and iterated on the process of. The basic structure is just go over the commits from the past 2 days (since we do it Tues/Thurs). You have to rely on the person running the meeting to 1) know what's important to spend extra time on and 2) keep the meeting rolling along through the meaty, important commits. This requires a decent amount of knowledge in the domain area as well as some good sense of the pulse for what's being worked on across different teams so they know when to surface things that would be important for cross-communication. That and even having a sense for good mentoring opportunities (e.g. people keep having trouble with `async/await` so I'll call out this commit with really good examples of using that feature).

So, all and all, the person leading it is one of the most important things. Having a good culture that's open to healthy constructive feedback is super helpful and allows you to dive into some conversations ripe with growth opportunities. It's one of my favorite things we do at our company!

[zaphod4prez]

Thank you, that's so helpful! This is a really great idea

[mavelikara]

How big is your team?

[khalilravanna]

When we started we had maybe 4 engineers going. Now it's like 12 going to the meeting. It's a bit more unwieldy but still works.

What we've talked about is basically if it continues to grow we'll need to be a lot more structured or have to splinter off into groups with a good ratio of experienced to less-experienced engineers to still maintain learning.