Hi HN, I've been organizing a systems reading group at Microsoft for five years now. I wrote down some takeaways on what worked (and what didn't). I'd love to hear if anyone else has successfully kept an engineering reading group alive at their company, or if you have any favorite systems papers we should add to our list!
This is great and congrats on the success. Many years ago I tried starting a cybersecurity reading group in my city since the startup I was working at was small and people there weren’t interested in that topic. I got a lot of very green, aspiring and non-professionals to show up. We couldn’t really agree on where to start and people had different ideas of where to focus or even how much they wanted to contribute. Mostly people wanted to hear a summary and didn’t really put in the kind of effort that I had hoped. It didn’t last long. Congrats again on making it 5 years and covering so much ground.
I gave a long post at the top level about running a book-focused reading group at a company, but your group sounds more like a Papers We Love[1] chapter.
I used to co-host the San Diego chapter of Papers We Love[2], and here's my secret sauce: I offered to meet with every presenter in advance for a dry run of their presentation. Probably two thirds of the presenters took me up on the offer.
For the group and the presenter, going through a dry run had the positive impact you would expect on presentation quality.
The benefit for me was that I got one-on-one discussion/learning with a wide variety of people passionate about a broad range of papers, and I also got to go through the material twice. So I learned much more and retained it better.
I understand that in a research lab or in academia, this is common practice. But in the more menial coding industry that most of us are probably in, how do you find time for this? Do people read papers in their spare time and discuss over lunch, or are there enlightened managers who support this during working hours?
I would be interested to hear others experiences with running these types of groups. We’ve tried this a couple of times at my current job and both times it’s petered out - people don’t do the assigned reading and then just stop attending.
Any suggestions on how to keep such a group alive?
I've seen such reading groups. I worked for Atlassian, and there was a reading group. My impression is it was organized only as a low effort just to demonstrate that IC is going extra mile for the company. The quality of such reading groups were quite low. And it was expected that you would attend this reading group at a lunch time. You're taking your lunch with you, and instead of enjoying your meal, you're cramped in a small room with coworkers who also got their sandwiches and sugar soda. Horrible experience, and zero value.
I ran reading groups over several years a medium-sized startup I worked for and for an open source community I was a part of. The groups were targeted not only at engineering staff but also semi-technical positions such as product management and low-skilled data pipeline specialists, with the aim of building bridges between departments and internal recruitment.
Running those reading groups was basically how I acquired a lot of knowledge I didn't get because I didn't major in Comp Sci as an undergrad.
Books/MOOCs we went through:
* Pro Git (Chacon) [three times]
* Programming Language Pragmatics (Scott)
* Calculus first semester (Coursera/OSU/Fowler)
* Eloquent JavaScript (Haverbeke)
* Learning Perl (Schwartz/Foy) [two or three times]
* Coding the Matrix (Coursera/Brown/Klein) [didn't finish]
* Object-Oriented Programming: An Evolutionary Approach (Cox)
* Learning Core Audio (Adamson/Avila)
The level of commitment from the participants was mixed. Nobody came for the free lunch (although arranging free lunch was essential in getting people to show up). Many people had ambitions that outstripped their commitment. But there were plenty of people who took advantage and learned tons.
One fellow, who I feel immensely fortunate to have known, went from zero experience to arguably our most productive IC within 2 years, and eventually landed at a FAANG. He also took a turn leading the discussion group.
Another participant was a Product Manager who became much better able to communicate with Engineering after improving her understanding of programming fundamentals.
The sessions were generally organized around questions that people would bring about the material — my motto was "we'll struggle through together". I preferred questions posed by others but always had enough of my own to fill space.
The tips I would have for people running such groups:
First you need a discussion leader. You need someone who can get the group unstuck and who knows the material. It's the same dynamic as having a good TA for a college discussion section.
Second, remove all friction. Corporate won't buy books? Screw it, I bought 'em myself. Corporate won't arrange for lunch? Screw it, I bought it for everybody. (Our CTO was highly supportive but once the company got acquired we couldn't get budget approved anymore). The total outlay I made leading the group was a few thousand dollars — far less than I would have paid for formal courses where I would have learned less.
Congratulations on the five year mark! I co-run a similar paper reading group at Zalando (European e-commerce) and recently shared our learnings/experience[1] of running such a group for over a year and I'm happy to see so many similarities.
We focus our papers around distributed systems, software engineering and languages and try to cover more ground on the applications of the concepts discussed in the papers. The blog post also contains a "blueprint" for someone who is looking to start a similar group.
What has driven the meetups throughout the year is we being two organisers, driving the topic ourselves by preparing a presentation (not everyone would have the time to pre-read) and making the format conversational/open - very similar to what Armaan (op) shared.
One of our recent experiments was doing a collab with the Berlin Systems Group[2] where we organised an external-facing event in Berlin with attendees from outside our organisation. I was so happy to see a nice small group turn up for the event and thoroughly enjoy it!
13 comments
[ 2.6 ms ] story [ 32.0 ms ] threadBTW heard about this paper[1] a few weeks ago, but not completely aligned with database and probably a bit too introductory for your group.
[1]https://www.cs.fsu.edu/~awang/courses/cop5611_s2024/vnode.pd...
I used to co-host the San Diego chapter of Papers We Love[2], and here's my secret sauce: I offered to meet with every presenter in advance for a dry run of their presentation. Probably two thirds of the presenters took me up on the offer.
For the group and the presenter, going through a dry run had the positive impact you would expect on presentation quality.
The benefit for me was that I got one-on-one discussion/learning with a wide variety of people passionate about a broad range of papers, and I also got to go through the material twice. So I learned much more and retained it better.
[1] https://paperswelove.org/
[2] https://www.youtube.com/channel/UCYPNnoVAQqb2Mue9v9f2euA
Any suggestions on how to keep such a group alive?
Running those reading groups was basically how I acquired a lot of knowledge I didn't get because I didn't major in Comp Sci as an undergrad.
Books/MOOCs we went through:
* Pro Git (Chacon) [three times]
* Programming Language Pragmatics (Scott)
* Calculus first semester (Coursera/OSU/Fowler)
* Eloquent JavaScript (Haverbeke)
* Learning Perl (Schwartz/Foy) [two or three times]
* Coding the Matrix (Coursera/Brown/Klein) [didn't finish]
* Object-Oriented Programming: An Evolutionary Approach (Cox)
* Learning Core Audio (Adamson/Avila)
The level of commitment from the participants was mixed. Nobody came for the free lunch (although arranging free lunch was essential in getting people to show up). Many people had ambitions that outstripped their commitment. But there were plenty of people who took advantage and learned tons.
One fellow, who I feel immensely fortunate to have known, went from zero experience to arguably our most productive IC within 2 years, and eventually landed at a FAANG. He also took a turn leading the discussion group.
Another participant was a Product Manager who became much better able to communicate with Engineering after improving her understanding of programming fundamentals.
The sessions were generally organized around questions that people would bring about the material — my motto was "we'll struggle through together". I preferred questions posed by others but always had enough of my own to fill space.
The tips I would have for people running such groups:
First you need a discussion leader. You need someone who can get the group unstuck and who knows the material. It's the same dynamic as having a good TA for a college discussion section.
Second, remove all friction. Corporate won't buy books? Screw it, I bought 'em myself. Corporate won't arrange for lunch? Screw it, I bought it for everybody. (Our CTO was highly supportive but once the company got acquired we couldn't get budget approved anymore). The total outlay I made leading the group was a few thousand dollars — far less than I would have paid for formal courses where I would have learned less.
If I had my time again I'd honestly just apply for job 1 make ends meet then continously apply to get a job like this where you can go deep.
Money is probably good but just for the interestingness. That DCOM and SOAP shit I did is worthless now. Most tech is non compounding.
We focus our papers around distributed systems, software engineering and languages and try to cover more ground on the applications of the concepts discussed in the papers. The blog post also contains a "blueprint" for someone who is looking to start a similar group.
What has driven the meetups throughout the year is we being two organisers, driving the topic ourselves by preparing a presentation (not everyone would have the time to pre-read) and making the format conversational/open - very similar to what Armaan (op) shared.
One of our recent experiments was doing a collab with the Berlin Systems Group[2] where we organised an external-facing event in Berlin with attendees from outside our organisation. I was so happy to see a nice small group turn up for the event and thoroughly enjoy it!
[1] https://engineering.zalando.com/posts/2026/01/running-an-eng... [2] https://luma.com/y9edbih7