Recipes for running a successful technical book club at work
(Bob Raman, Wai Chee Yau and Darragh Kennedy)
This blog post is our learnings from running technical book clubs at Zendesk for the past 2 years. In that time we have run four book clubs:
- Two books on functional programming languages: Clojure and Scala
- Reliability is very important to us so we studied the bible on Software Reliability Engineering from Google
- Recently we read, Designing Data–Intensive Applications by Martin Kleppmann as we do a lot of data processing.
We have a strong learning culture at Zendesk and we constantly encourage our employees to improve their craft. Book clubs can be a effective way to stay up to date with latest technologies and best practices and learn with your colleagues in a safe environment.
We studied the Clojure book because we use Clojure for all our work with Map-reduce (Cascalog) and we had a bunch of new hires unfamiliar with Clojure.
We also wanted to move to Spark from Map-Reduce and the team thought Scala might be a good choice for that — hence the Scala book.
The SRE book came about because as a company Zendesk wanted to do better with reliability of our systems — learn from the experts like Google on how to build reliable systems seemed like a good approach.
We have to build our systems at scale to support the 110,000 customers that Zendesk has. The Kleppmann book is a thorough deep-dive into the fundamentals of distributed data systems. Kleppmann does not focus on any particular technology but helps to map out the questions you should answer before you choose a data system.
Once we had established interest from a core group of people we reached out to all the people at our office in Melbourne to garner interest. With all the book clubs that we ran people from multiple groups attended not just engineering including Operations and Sustaining.
In some cases a book is so exemplary that it chooses itself — Google SRE book was one. With Clojure and Scala we discussed what topics were of interest for us and did some research on StackOverflow, Quora, read blogs, etc to see what people were saying about the various texts. As well we shared the list of books on Slack and got feedback from the team and experts and champions within the company. The Kleppmann book came along at the perfect time as it covered many of the technical challenges we were dealing with.
One good sanity check is to read a chapter from the book that you have chosen to check that the books would be easy to consume for the group and has a decent set of problems to tackle.
Running the book club
Some logistics that are worth setting up at the start are:
- Setup a recurring calendar invite for all concerned.
- Also setup a Slack channel where people can discuss the chapters in the book as they go and share other related information that they come across such as blogs, etc. Encourage the ad-hoc discussions in these channels as they help with better understanding of the topics being studied.
- A wiki page where you can keep track of any additional resources and summaries.
- A github repo for programming books so that you can share problems and solutions.
In terms of running the book club we did the following:
- Used the first week to work out the rules or format for the book club.
- Let someone different lead a chapter each week — ask for volunteers at the end of each session. You need the diverse set of experiences and skills from different people to aid the learning of the group.
- For programming books — if you have a 1hr session each week then spend 15 minutes to summarise the chapter, 35 minutes to do some problems and 10 minutes to work through the solution. The person leading that week should set the problem and share the solution. We found that doing problems was a good way to accelerate learning.
- For non-programming books get people to write a summary of the chapter beforehand as this helps those present to learn — especially the salient points.
- For non-programming books try to relate the information to your company context. This usually leads to some really useful discussions and learnings.
- Importantly encourage people to attend even if they have not read the chapter as they can learn a lot from the discussions. We found this particularly useful for non-programming books such as the SRE book.
- Ask questions of the group on some of the material, this can help to get discussion going rather than passively reading through the chapter.
- Do not cancel or change the time of the book club. It is fine for people to miss a week or two due to conflicts but keeping to a schedule encourages attendees to set aside time to attend.
Most of the book clubs ran for around 2–3 months though the SRE book due to its size (34 chapters) ran for about 6 months.
The book club typically had large turnout at the start then eventually settled on around a third of the original size. We had as many as 30 for the SRE book at the start and then settled on about 10 people.
We found that 10 is around the upper limit of people for discussions. When we had more than 10 we typically split into multiple groups and discussed the same chapter separately in each group.
Energise the book club
Gentle pings on slack a few days before the next session usually helps. Also rotating who leads the next session definitely helps with motivation.
Remember though that people are busy and are working to different deadlines so if is it possible to have material that is not dependent on earlier chapters then it can often work well. Encourage people to come even if they have missed some weeks.
If you are the organiser of the book club then you should always read a few chapters ahead at a minimum so that you can direct which chapters could be skipped for example. Also if people call in sick you can step in and lead a chapter. In our case we usually skim through the entire book so that we have a good handle on contents before we start the book.
Passion for the topic helps a lot and when a book has 34 chapters, like the SRE book then you do need to persevere.
- Do not constrain yourself to only the material in the book if it helps your team. For the Clojure book we studied core-async outside the text that we were studying. We also have state in our Clojure apps so we also studied https://github.com/stuartsierra/component
- We use Akka so when we studied Scala text which does not contain description of Akka we studied outside examples and looked at production code that we had.
- You are learning so that you can apply knowledge to a given situation so read the book from the lens of that context.
- If the learnings from the book are more generally valuable then give tech talks to the entire company. In the case of the SRE we gave 5 talks that summarised the contents to all of engineering. At a minimum this exposes your engineering team to the ideas in the book and hopefully motivates people to go and read a chapter or two. eg. “Error budget” is a concept that more people in the engineering team now understand.
- Take time to understand what use cases you want to use a particular language for. In our case we missed that one team wanted to use Akka.
- Generate follow-up discussion in the Slack channel, attendees often posted interesting blogs, videos, papars that related to the days discussion.
- Set your team up so that anyone can propose a book club. People read blogs and work on improving their craft all the time. Empowering developers to start a book club are a great way to share knowledge.
- Encourage people from multiple groups to attend. You need the diverse set of skills and experiences to help the group learn new things.
- Do not hesitate to re-run the book multiple times especially if you are a company that is growing fast. Ask someone else to volunteer to run the book club next time.
Check with your management peers if they are okay with everyone devoting one hour of working time each week in a book club.
Try not to run book clubs at lunch time — if the material is important then you should use work time for it.
Figure out who is going to pay for the books — in my case I sent out a site wide email asking for interest and reached out to Zendesk MD & VP in Melbourne Brett Adam who was kind enough to pay for the books. If your organization has professional development funds allocated to staff, that could be another source as well
Get a list of names of people who wanted physical copies and those happy with soft copies. If your org has a Professional Development setup then you could probably let individuals pay for it that way. People do really appreciate you doing the extra yards on ordering the books and delivering it to them — definitely worth the effort. If your company has Safari subscription or something similar then organising books may be much easier for you.
Book clubs are a great way to level up your team/s in a particular area in a safe environment. Keeping the book club cross-team also helps build social connections and collaboration across teams.
If you are a Data Engineering team then apart from the books mentioned above you may be interested in the following (likely next book for us):
- https://www.manning.com/books/functional-programming-in-scala — Awesome book on functional programming in Scala. Probably one you would do after you have done an introductory Scala book.