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?
Good question. Most people read the paper on their own time, and we meet over lunch. The meetings themselves are just an hour, so it's not a massive time block. I've found that the people who show up are the ones who are genuinely curious and would be reading this stuff anyway (and sometimes just need a commitment/accountability to do it). Having a group gives them a reason to do it on a schedule.
We usually start with quick overall impressions, then go around with a few prompts: "what's something new you learned?", "what didn't you like?", and "what didn't you fully understand?" (every paper has something, whether it's the evaluation methodology or some algorithm detail). That last question tends to drive most of the discussion because people chime in and build on each other's answers. Sometimes you get lucky with domain expertise in the room. For example, when we read "What Every Programmer Should Know About Memory"[1], one of the attendees was a former Intel engineer who spent their career in memory systems. They answered questions the rest of us wouldn't have even known to ask.
That implies that you have a fixed time for lunch and also chat during lunch. I may be the minority but I prefer to eat when I'm hungry and focus on the food instead of chatting. And there is also allergies, as a celiac, I have big troubles eating together with others - they may accidently contaminate my food
I’m actually curious here, not trying to question your experience but does other people’s food regularly contaminate your food when you eat at the same table as them?
I’ve lived with a celiac sufferer before and I’ve never heard of something that extreme, but everyone’s different.
The degree of sensitivity of allergies varies widely. For example there are people who only have a problem after consuming a large scoop of peanut butter but there are also those who will end up in the hospital from trace amounts that you'd have difficulty spotting with the naked eye.
I dated a woman with celiac sprue (which I guess was extreme.. her mother had to have a bowel resection due to celiac related issues) and she had sudden anaphylaxis at a restaurant that required the use of an epi-pen and an ambulance.
The reaction was caused by the micro-brewery that had opened next door and all the wheat dust in the ventilation system.
It sounds like you could get very high ROI from chilling out a little bit. If one social lunch per month is an unfathomable hardship then you're probably leaving a lot of other opportunities on the table. Do you have OCD or social anxiety or something?
I'm not sure what you mean by menial coding but all my employers have supported this in the past. This was a variety of companies, big tech, startups, etc. I think its more likely your employer is the outlier.
All the companies I've worked at implicitly assume that you're supposed to use your working hours for more than just coding, including learning what you need for the task at hand, although if you're looking at very beginner material that might raise some suspicion.
In the case I mentioned above, the company wanted me to build a search engine before elastic search existed, and before there was full-text search in popular dbs like Postgres or MySQL. The CTO/founder gave me his credit card and told me to buy whatever books I needed. I bought about 5 different relevant books. Work days were about 10-12hrs, they still wanted me to read/research on my own time
In 35 years in the industry, reading and studying during work hours were always supported. Frankly, most places would let us play video games during work hours as long as we met our deadlines.
I've had mandated gaming on Friday after lunch. But this was in the gaming industry so it's "market research"!
We also often played board games. My favourite was playing secret Hitler with my team that one time. That was fun! (I managed to become "untouchable" while also being Hitler. That's a memorable moment!)
Interestingly, the person at Microsoft states in a reply that even most of them have to pick this up in their spare time. Judging from other replies, it seems that there are quite some differences in how companies approach this.
What I meant with "menial coding" is those jobs where people have to submit TPS reports on how much hours they spend for each customer. Reading a paper such as this one [1] is typically not directly necessary for being a good frontend developer, but it might stimulate someone to develop into a more fruitful employee in the long run. Managers would have to explain to their customer why time is being spent on that, and that requires some vision and creativity, which is not always a given.
The groups I ran were scheduled during lunch. Technical management would look the other way if we ran over time or if people spent a certain amount of their work day reading the material.
Even if you have enlightened technical management, it's helpful if you don't force them to spend political capital justifying groups like this. Getting our enlightened CTO to spend a few hundred dollars on books was easy when we were a startup. Once we got acquired, making that argument to unreceptive higher-ups wasn't worth it for anybody.
In my experience it is a lot like finding time to work on "strategy". There's never really explicit time given, you have to make it in the day, and its often the most valuable time spent.
This is a very good question. I also struggle to find a good solution to process various signals (papers, tecniques, etc.) with my co-workers while maintaining proper work-life balance. Either you have to be a full time geek, or be left behind..
I sneak thirty minutes in here and there for it regardless of my manager. If you work, say, 40-45 hours a week, you’re probably doing 20 hours of true focused productivity. It’s easier to borrow here and there from the other half of the time to flip through a paper or two.
If it happens in the office and on the calendar then I can't imagine it being an issue? (vs. an extended jolly at the pub every lunch through the afternoon for unofficial 'reading group'!) Would take quite a micromanaging and anti-L&D employer/manager.
Speaking as a SWE manager who explicitly “mandates” (not actually mandatory but I strongly encourage following your passions and interests in an academic kind of way!) we do exist, I assume I’m not the only one :)
My team almost always can find an hour between tasks organically so I’ve never really had to push
I'm a SWE manager as well. I always tell my team that learning is part of the job, and so it can happen on the job. To be honest, it worked out pretty well. and I lead by example, I'll read something interesting during work and share it with the team.
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!
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.
The dry run idea is really smart. We've done something similar, where we had Niv Dayan[1] lead a session on Diva[2] (before it won Best Paper at VLDB 2025!). I had worked with him in the past and thought it would be cool to have him present to the group. Having the author in the room completely changed the quality of the discussion. Most of our sessions right now aren't presenter-led, but I'd like to do more of that.
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.
Thank you! I think the biggest factor for us was that most attendees already had some technical baseline. That makes it way easier to pick papers and have productive discussions. A cross-experience group sounds much harder. We occasionally have non-technical people who attend (e.g., designers), but they usually are very eager to learn. The guided series format might have helped in your case, where you pick the topic and sequence upfront so there's less debate about direction each meeting. Honestly, just getting people to show up is hard at first, so the fact that you got it off the ground at all says something.
> I think the biggest factor for us was that most attendees already had some technical baseline. That makes it way easier to pick papers and have productive discussions.
Thanks for sharing your experience.
How do you suss out peoples technical aptitude, and what was the minimum level you were looking for?
The group is open to anyone at Microsoft and I don't gatekeep. The papers themselves act as a natural filter. If someone finds the material interesting, they attend and keep coming back. If it's not their thing, they self-select out. Over time, it's led to a core group of regular attendees as well as many who will join ad-hoc.
There are other groups within Microsoft, but they usually follow a presentation format rather than a collaborative discussion. Off the top of my head, Phil Bernstein[1] and Hanuma Kodavalla[2] run great database seminars for invited speakers. I regularly attend and have presented in both forums; Phil's crowd is mostly researchers, while Hanuma's is mostly full of SQL engineers. Different from a small reading group, but still great.
Appreciate the paper link! We like going back to the basics sometimes, so I'll definitely take a look.
It depends on the theme. If we're picking something in a space the group already knows well, like databases, I'll look at "Best Papers" from recent VLDB/ICDE/SIGMOD conferences. If we're exploring a topic most people are unfamiliar with, we'll go with something more foundational instead. For example, we're starting an arc on datacenters (servers, racks, networking, load balancing, power, cooling, failures, etc.), and most attendees don't have deep background there, so I found a book on the topic that we're going to read through[1].
Not author, but in the past I was just going through papers on biggest conferences for the last year and checked what sounded interesting for my own education. But it was a bit of a chore. What I tried now is use gemini thinking research and asked it to do just that, go through main software/hardware conferences for last 3 years, find me papers on the topics of interest and give summary and links. The result is pretty good!
I agree with you. I spend me free time deep-diving in such topics. I find hard to use this knowledge in a useful way at my job. The job market for deep topics is hard to penetrate.
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!
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 lead a book club once (Designing Data Intensive Applications)- read a chapter and meet every two weeks. Was a real flop. Attendance remained high, but only one other person actually finished the book.
What was a real slap in the face - maybe a year after that book had concluded, someone told me I should lead another one about this other topic. She had not finished the first book, and she wanted me to regurgitate another to the group?
Maybe there was value in the discussions that didn’t require the reading? But running seminars isn’t hobby material. If this was happening at my work, I may skim or not even read parts of the book, and still attend discussions.
I co-run a similar group at my company (added a comment above), what has worked for us and we realised this early on: not everyone will have the time to read and hence the sessions need to have a driver/lead. Assigning reading does not work unfortunately as many attend such groups voluntarily in addition to their primary work.
We as organisers (better to have at least 2) prepared before hand, either a presentation or a document, and then presented it in the group. While doing this, the group is free to discuss and interrupt at any time (we chose a slighly informal venue in the office).
Gradually, after about 10 sessions, we started seeing voluntary interest from the attendees to present a paper. And honestly this was an amazing feeling. So I'd suggest first finding a co-organiser who is interested in doing this and then pushing through the initial sessions by driving the topic yourself. That said, since you are preparing, you are free to choose the papers. We saw that if you choose papers related to a common larger theme that you are interested in, people would show up. Initially the attendance would be low, but with regular meetings, you'd start seeing regulars.
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’m sorry that you find the modal experience in reading groups to be bad?
It seems like the reading group that the OP put together was really successful. Most are not. That’s not really the fault of someone else for sharing their experience.
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.
Wow, Cox's original Objective-C book? Interesting historically, but it's hard to imagine it was of much pragmatic use, even if you're working in Obj-C as your day-to-day. Still, it's an interesting artifact of the early OO age, and the metaphor of libraries of objects as integrated circuits was interesting.
Yes! And I wouldn't have picked it, but I went along with it when someone else wanted to read it.
The "software IC" metaphor may not have caught on, but these artifacts of early experimentation, competitors against what evolved into mainstream OOP, are many times more interesting to read than the Nth "OOP sux" article.
EDIT: I just went back over some of my notes... Cox predicted that companies would compete to provide different implementations of common interfaces ("software ICs"). In restrospect, that didn't happen but Cox's prediction was wrong in such an interesting way: software orgs rather than customers assumed control over interfaces.
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?
Good question. Most people read the paper on their own time, and we meet over lunch. The meetings themselves are just an hour, so it's not a massive time block. I've found that the people who show up are the ones who are genuinely curious and would be reading this stuff anyway (and sometimes just need a commitment/accountability to do it). Having a group gives them a reason to do it on a schedule.
> The meetings themselves are just an hour, so it's not a massive time block
How exactly are the meetings structured? I.e is someone leading discussions? Does each person go around and share thoughts? Etc
We usually start with quick overall impressions, then go around with a few prompts: "what's something new you learned?", "what didn't you like?", and "what didn't you fully understand?" (every paper has something, whether it's the evaluation methodology or some algorithm detail). That last question tends to drive most of the discussion because people chime in and build on each other's answers. Sometimes you get lucky with domain expertise in the room. For example, when we read "What Every Programmer Should Know About Memory"[1], one of the attendees was a former Intel engineer who spent their career in memory systems. They answered questions the rest of us wouldn't have even known to ask.
[1] https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
That implies that you have a fixed time for lunch and also chat during lunch. I may be the minority but I prefer to eat when I'm hungry and focus on the food instead of chatting. And there is also allergies, as a celiac, I have big troubles eating together with others - they may accidently contaminate my food
I’m actually curious here, not trying to question your experience but does other people’s food regularly contaminate your food when you eat at the same table as them?
I’ve lived with a celiac sufferer before and I’ve never heard of something that extreme, but everyone’s different.
The degree of sensitivity of allergies varies widely. For example there are people who only have a problem after consuming a large scoop of peanut butter but there are also those who will end up in the hospital from trace amounts that you'd have difficulty spotting with the naked eye.
I dated a woman with celiac sprue (which I guess was extreme.. her mother had to have a bowel resection due to celiac related issues) and she had sudden anaphylaxis at a restaurant that required the use of an epi-pen and an ambulance.
The reaction was caused by the micro-brewery that had opened next door and all the wheat dust in the ventilation system.
When I've seen this done, yeah you block a fixed time for a "meeting", durring lunch time.
It sounds like you could get very high ROI from chilling out a little bit. If one social lunch per month is an unfathomable hardship then you're probably leaving a lot of other opportunities on the table. Do you have OCD or social anxiety or something?
Apparently, people with celiac disease do have "anxiety or something":
https://en.wikipedia.org/wiki/Coeliac_disease#Dietary_challe...
I'm not sure what you mean by menial coding but all my employers have supported this in the past. This was a variety of companies, big tech, startups, etc. I think its more likely your employer is the outlier.
I’ve been scolded for reading books and documentation for the tasks and software I was asked to build (at a startup) during my regular work hours
No company I’ve worked at has ever had dedicated time for reading papers or articles
Maybe I’ve only worked at outliers?
All the companies I've worked at implicitly assume that you're supposed to use your working hours for more than just coding, including learning what you need for the task at hand, although if you're looking at very beginner material that might raise some suspicion.
In the case I mentioned above, the company wanted me to build a search engine before elastic search existed, and before there was full-text search in popular dbs like Postgres or MySQL. The CTO/founder gave me his credit card and told me to buy whatever books I needed. I bought about 5 different relevant books. Work days were about 10-12hrs, they still wanted me to read/research on my own time
In 35 years in the industry, reading and studying during work hours were always supported. Frankly, most places would let us play video games during work hours as long as we met our deadlines.
I've had mandated gaming on Friday after lunch. But this was in the gaming industry so it's "market research"!
We also often played board games. My favourite was playing secret Hitler with my team that one time. That was fun! (I managed to become "untouchable" while also being Hitler. That's a memorable moment!)
Interestingly, the person at Microsoft states in a reply that even most of them have to pick this up in their spare time. Judging from other replies, it seems that there are quite some differences in how companies approach this.
What I meant with "menial coding" is those jobs where people have to submit TPS reports on how much hours they spend for each customer. Reading a paper such as this one [1] is typically not directly necessary for being a good frontend developer, but it might stimulate someone to develop into a more fruitful employee in the long run. Managers would have to explain to their customer why time is being spent on that, and that requires some vision and creativity, which is not always a given.
[1] https://arxiv.org/abs/1706.03762
Thats my experience as well. Of course not ten paper a day but some learning is always encouraged.
One company had a +1 day. You worked 4 days, had 1 day for learning - everything relevant for the job was fine.
The groups I ran were scheduled during lunch. Technical management would look the other way if we ran over time or if people spent a certain amount of their work day reading the material.
Even if you have enlightened technical management, it's helpful if you don't force them to spend political capital justifying groups like this. Getting our enlightened CTO to spend a few hundred dollars on books was easy when we were a startup. Once we got acquired, making that argument to unreceptive higher-ups wasn't worth it for anybody.
In my experience it is a lot like finding time to work on "strategy". There's never really explicit time given, you have to make it in the day, and its often the most valuable time spent.
This is a very good question. I also struggle to find a good solution to process various signals (papers, tecniques, etc.) with my co-workers while maintaining proper work-life balance. Either you have to be a full time geek, or be left behind..
I sneak thirty minutes in here and there for it regardless of my manager. If you work, say, 40-45 hours a week, you’re probably doing 20 hours of true focused productivity. It’s easier to borrow here and there from the other half of the time to flip through a paper or two.
If it happens in the office and on the calendar then I can't imagine it being an issue? (vs. an extended jolly at the pub every lunch through the afternoon for unofficial 'reading group'!) Would take quite a micromanaging and anti-L&D employer/manager.
Speaking as a SWE manager who explicitly “mandates” (not actually mandatory but I strongly encourage following your passions and interests in an academic kind of way!) we do exist, I assume I’m not the only one :)
My team almost always can find an hour between tasks organically so I’ve never really had to push
I'm a SWE manager as well. I always tell my team that learning is part of the job, and so it can happen on the job. To be honest, it worked out pretty well. and I lead by example, I'll read something interesting during work and share it with the team.
You could realistically read 2-3 papers per visit to HackerNews if you were doing that instead. Me too.
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!
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.
[1] https://paperswelove.org/
[2] https://www.youtube.com/channel/UCYPNnoVAQqb2Mue9v9f2euA
The dry run idea is really smart. We've done something similar, where we had Niv Dayan[1] lead a session on Diva[2] (before it won Best Paper at VLDB 2025!). I had worked with him in the past and thought it would be cool to have him present to the group. Having the author in the room completely changed the quality of the discussion. Most of our sessions right now aren't presenter-led, but I'd like to do more of that.
[1] https://scholar.google.com/citations?user=vdMOvmIAAAAJ [2] https://www.vldb.org/pvldb/vol18/p3923-eslami.pdf
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.
Thank you! I think the biggest factor for us was that most attendees already had some technical baseline. That makes it way easier to pick papers and have productive discussions. A cross-experience group sounds much harder. We occasionally have non-technical people who attend (e.g., designers), but they usually are very eager to learn. The guided series format might have helped in your case, where you pick the topic and sequence upfront so there's less debate about direction each meeting. Honestly, just getting people to show up is hard at first, so the fact that you got it off the ground at all says something.
> I think the biggest factor for us was that most attendees already had some technical baseline. That makes it way easier to pick papers and have productive discussions.
Thanks for sharing your experience.
How do you suss out peoples technical aptitude, and what was the minimum level you were looking for?
How were your discussions structured?
The group is open to anyone at Microsoft and I don't gatekeep. The papers themselves act as a natural filter. If someone finds the material interesting, they attend and keep coming back. If it's not their thing, they self-select out. Over time, it's led to a core group of regular attendees as well as many who will join ad-hoc.
Interesting. We don't have an engineering culture, so definitely no. Did you find similar groups within MSFT?
BTW 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...
There are other groups within Microsoft, but they usually follow a presentation format rather than a collaborative discussion. Off the top of my head, Phil Bernstein[1] and Hanuma Kodavalla[2] run great database seminars for invited speakers. I regularly attend and have presented in both forums; Phil's crowd is mostly researchers, while Hanuma's is mostly full of SQL engineers. Different from a small reading group, but still great.
Appreciate the paper link! We like going back to the basics sometimes, so I'll definitely take a look.
[1] https://en.wikipedia.org/wiki/Phil_Bernstein
[2] https://scholar.google.com/citations?user=9eNQbZUAAAAJ&hl=en
Thanks for the references!
Any tipps on finding interesting and valuable papers?
It depends on the theme. If we're picking something in a space the group already knows well, like databases, I'll look at "Best Papers" from recent VLDB/ICDE/SIGMOD conferences. If we're exploring a topic most people are unfamiliar with, we'll go with something more foundational instead. For example, we're starting an arc on datacenters (servers, racks, networking, load balancing, power, cooling, failures, etc.), and most attendees don't have deep background there, so I found a book on the topic that we're going to read through[1].
[1] https://link.springer.com/book/10.1007/978-3-031-01761-2
Not author, but in the past I was just going through papers on biggest conferences for the last year and checked what sounded interesting for my own education. But it was a bit of a chore. What I tried now is use gemini thinking research and asked it to do just that, go through main software/hardware conferences for last 3 years, find me papers on the topics of interest and give summary and links. The result is pretty good!
I am so jealous. 25 years of crud and framework chasing and I'd never get close to that. I am slightly closer now but not much.
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.
I agree with you. I spend me free time deep-diving in such topics. I find hard to use this knowledge in a useful way at my job. The job market for deep topics is hard to penetrate.
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!
[1] https://engineering.zalando.com/posts/2026/01/running-an-eng... [2] https://luma.com/y9edbih7
[dead]
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 lead a book club once (Designing Data Intensive Applications)- read a chapter and meet every two weeks. Was a real flop. Attendance remained high, but only one other person actually finished the book.
What was a real slap in the face - maybe a year after that book had concluded, someone told me I should lead another one about this other topic. She had not finished the first book, and she wanted me to regurgitate another to the group?
Maybe there was value in the discussions that didn’t require the reading? But running seminars isn’t hobby material. If this was happening at my work, I may skim or not even read parts of the book, and still attend discussions.
There can be value, it's a networking opportunity and some companies could look favorably on it for promos.
I co-run a similar group at my company (added a comment above), what has worked for us and we realised this early on: not everyone will have the time to read and hence the sessions need to have a driver/lead. Assigning reading does not work unfortunately as many attend such groups voluntarily in addition to their primary work.
We as organisers (better to have at least 2) prepared before hand, either a presentation or a document, and then presented it in the group. While doing this, the group is free to discuss and interrupt at any time (we chose a slighly informal venue in the office).
Gradually, after about 10 sessions, we started seeing voluntary interest from the attendees to present a paper. And honestly this was an amazing feeling. So I'd suggest first finding a co-organiser who is interested in doing this and then pushing through the initial sessions by driving the topic yourself. That said, since you are preparing, you are free to choose the papers. We saw that if you choose papers related to a common larger theme that you are interested in, people would show up. Initially the attendance would be low, but with regular meetings, you'd start seeing regulars.
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.
What a buzzkill and a super negative comment.
I’m sorry that you find the modal experience in reading groups to be bad?
It seems like the reading group that the OP put together was really successful. Most are not. That’s not really the fault of someone else for sharing their experience.
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.
Wow, Cox's original Objective-C book? Interesting historically, but it's hard to imagine it was of much pragmatic use, even if you're working in Obj-C as your day-to-day. Still, it's an interesting artifact of the early OO age, and the metaphor of libraries of objects as integrated circuits was interesting.
Yes! And I wouldn't have picked it, but I went along with it when someone else wanted to read it.
The "software IC" metaphor may not have caught on, but these artifacts of early experimentation, competitors against what evolved into mainstream OOP, are many times more interesting to read than the Nth "OOP sux" article.
EDIT: I just went back over some of my notes... Cox predicted that companies would compete to provide different implementations of common interfaces ("software ICs"). In restrospect, that didn't happen but Cox's prediction was wrong in such an interesting way: software orgs rather than customers assumed control over interfaces.
[dead]
[flagged]