22 replies
2d2h
Doing it at your company likely won't go well
This has been my experience. I led a book club at one of my jobs and it was poorly attended and those who did attend hadn't read the book.
My guess is that there is just a low percentage of people who meet all the criteria: 1) interested, 2) have the time to read the book, 3) have the commitment to read the book, and 4) social enough to attend the book club meeting.
I understand that many people are busy and may not have time to read the book or have a schedule conflict the day the book club meeting happens.
So unless your company is huge, you'll not have enough to keep a book club going. There also may be pressure to avoid using company communication tools to promote the club.
This has been my experience too. However, I found that changing the book club to “article club” where we all read one interesting technical article worked quite well. I have been running such a club with fortnightly meetings for over 3 years now.
Are you able to organize that on company time? Are you guys clocked in during your meetings?
I guess that wouldn't be unreasonable if the content is work related and certainly helps with attendance, but I'm not sure if that would fly within all corporations.
I've approved or started (or both) this sort of thing on company time before, at more than one place.
For context, this was typically early stage R&D, and many/most of the employees had some academic background, though that ranged from "decades ago" to "we just hired you after a masters degree".
In this setting, it's a pretty natural continuation of the common "journal club" approach in academic research groups. It spreads the effort around, helps the team stay on top of new work, and generally improves professional development - if done well. It does take a bit of effort to keep fresh.
I think most technology companies should have that, and I've been promoting that workplaces.
The trick to make it sustainable is to make at 3-month calendar of covered papers from multiple sub-areas (e.g. data management to machine learning, new programming languages to compiler topics) and share that widely. Not every topic is relevant to everyone, so naturally each topics will only attract a subset of the crowd beyond a small number of open-minded champions, but that's okay.
(Not OP) We tried launching a book club at one of our previous companies, where we were told "no worries, take your time to read a chapter a week and take an hour to talk about it.
While in theory, everybody thought it's a good idea, not everyone had time to read it, and when it came down to it, everybody just preferred to work on their regular tasks. In the end, nobody wants to risk delaying a promised deadline because of a book club.
So it all fizzled out within a month...
Maybe because I've been a reader my whole life, but I can't imagine getting value out of reading a chapter a week. It's rare for me to read less than 1 book per week. Even if it were a technical or educational book, one chapter at a time is a miserable way to read something.
Yeah. The company has a general culture of enabling learning, so this fits right in. The company also does a wider book club that focuses on more non-technical topics.
If you're a relatively senior engineer, any reasonable company will want you to be doing knowledge sharing (or outright mentoring - which this isn't, but it falls vaguely enough in the same bucket that you can usually get positive attention for it.)
(In a previous startup, we had cross-department tech talks, partly because we had some really specialized problems, so it was useful for, say, releng to hear about what the ML team thought was interesting, and vice versa, just for generally improving communication and reducing friction. We even threw in an occasional "lightning talk" session, which was popular, though it was as much for getting people comfortable giving talks so they could level up to bigger ones.)
Not OP, but I have worked at a few companies that would't mind, as long as the articles are relevant to your work. You could even sell it as a way to enrich everyone's expertise because of the deeper technical discussion.
Sounds fun. How do you get your list of articles?
It’s crowdsourced. People add to the list things they find interesting and would like discussed more widely. We also have round robin turns setup to decide who picks the next article to read from the pool.
Interested to hear more about this. What works well? What didn't?
We tried different models. One book every two months, one or more chapters of a book every month (thus finishing a whole book over a few months), and one article/video (generally requiring an hour of reading/watching time) every two weeks. My thoughts below are based on experience of those three models.
1. Reading a whole book every one or two months works well when everyone has a regular reading habit. Without that people realize that they need to read a whole book in a few days before the meeting. That either led to poor quality discussions or people showing up without reading. 2. Reading book chapters every month was less demanding but the frequency of meetings was still too low for people to build reading into their routines. 3. At two weeks the frequency was high enough that it became a routine for the engineers. 4. We also reminded everyone one day before to read the article. Even if they had forgotten to read till then it is easy to find and hour in the day to read up. 5. If the reminder was too far in advance (say 3 days before) then people ignored the reminder.
I ran a book club for 7 years when I worked at TriOptima. We were maybe 40 developers in total at the company, and around 10 would join when we picked a new book. Towards the end of one book, some people would always drop off, but there were still enough people to make it useful.
One of the key (unexpexted) benefits of it was how it facilitated discussions about SW development practices between the different teams at the company. The content was usually good for giving us new ideas to try etc, but the usefullness of the discussions surprised me.
I've written more about it here:
https://henrikwarne.com/2016/11/08/developer-book-club/
Thanks Henrik! Your blog post inspired me back then to start a book club at my company. It’s still running :-)
Great to hear!!
We did a book club at my previous company. We voted on the first book, Despair by Nabokov. The interesting thing is that the ones who voted on this book didn't end up reading it. The ones who did read that book had voted on something else and, at least in my case, forced themselves to read Despair.
My guess is that a lot of those people who voted on Despair and proposed it were trying to show off how smart and educated they were but those type of people don't actually follow through because it's work.
In the book club I run, we voted on books for a few years. I kept hoping the non-attending voters would choose the right books to bring them to a meeting, but the choices sometimes felt aspirational like that -- people voted for a heavy title but still didn't attend, and it was irritating to be reading dull books chosen by someone else.
So we switched to making selections in person at a session; if you can't come, you can submit suggestions, but the people who actually bother to show up make the final choices. We choose a monthly book for a whole year at a time, so we just do an hour-long discussion in December and pick 11 titles. In a monthly group you could probably do it in 10 minutes after the regular discussion.
Also, as the organizer feel free to put your thumb on the scale: pick 3 books you'd personally like to read, and ask them to choose one. You may want to be completely democratic about it, but people often appreciate someone else reading reviews and limiting the choices (avoiding the paradox of choice).
We ran a journal club at work, and it worked ok. The commitment boundary is significantly lower, and you can learn a lot from e.g. USENIX papers.
And 5) get something out of reading software books.
Not sure what it is, but in general software books just don't do much for me.
Only one I truly liked and got a lot out of was Physically Based Rendering[1]. It had a great blend of explaining the concepts but also showing how to implement them, and for me the literal programming style worked very well in this case.
But apart from that I struggle with getting something out of software books. Not fiction though, I read tons of sci-fi (especially hard) in my 20s.
[1]: https://www.pbrt.org/
My experience as well. I tried it a couple of times more than 10 years ago, one is covering Nancy Lynch's Distributed Algorithms, and one is Maurice Herlihy's The Art of Multiprocessor Programming. We finished about 1/4 of each of the books before running out of momentum. People simply lost interest as the content became increasingly challenging. We talked about the reasons, and the overwhelming feedback was that people lost interest because they failed to see what they learned could be applied to the job in short term, so it looked to them that the effort of learning the hard stuff wouldn't pay off.
We just started doing this and it was awesome to start but slowly I could tell people started becoming disinterested. We are contemplating another round which I think will be the deciding factor.