How exactly are the meetings structured? I.e is someone leading discussions? Does each person go around and share thoughts? Etc
No company I’ve worked at has ever had dedicated time for reading papers or articles
Maybe I’ve only worked at outliers?
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.
One company had a +1 day. You worked 4 days, had 1 day for learning - everything relevant for the job was fine.
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.
My team almost always can find an hour between tasks organically so I’ve never really had to push
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.
[2] https://www.youtube.com/channel/UCYPNnoVAQqb2Mue9v9f2euA
[1] https://scholar.google.com/citations?user=vdMOvmIAAAAJ [2] https://www.vldb.org/pvldb/vol18/p3923-eslami.pdf
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...
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
[1] https://link.springer.com/book/10.1007/978-3-031-01761-2
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
Any suggestions on how to keep such a group alive?
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?
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.
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.
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.
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.
