The System
When reading a technical book as a group, a good general rule of thumb is to cover a chapter a week. These kinds of books tend to be fairly dense, and trying to cover any more than that can overwhelm members of the group. But note that this can vary on a case by case basis, where some chapters in a book can be very short and could be combined, and other chapters can be overly long, and need to be further broken down.Additionally reading speeds will very from group to group and from topic to topic. So during the first few weeks of a new book, be sure to gauge the how well the group is keeping up with the pace, and either slow down or speed up accordingly. With this being the case, it will typically take 2 to 3 months to go through a book, varying from book to book.
Meeting regularly to discuss the book is important and valuable, and meeting weekly for about an hour is a good cadence. During this time it's useful have people discuss any points they found interesting from the book, share example code, have a presenter present a practice problem, which the group can then solve, mob programming style, and generally give opportunities for the group to experiment with what they read about. In addition, a facilitator may need a few minutes to address points with keeping the book club running smoothly, such as meeting times, reading schedules, next book, etc. We'll further discuss the facilitator and present roles in the following sections.
The Facilitator
The facilitator is there to keep things running smoothly. This includes a number of responsibilities, such as:- Determining what book to read. This involves first determining a topic, which can come from polling the group about interests or from determining business needs, and then from there researching what books are available on the topic. Note that while some technical books age well, many do not simply because of the rapid pace of change in the industry.
- Setting a reading schedule. Again, a good rule of thumb is a chapter a week, but be sure to look through the book and take into consideration the people in your group when determining this. And this doesn't need to be set in stone. If after a week or two, you find that the current pace isn't working for people, change it. Also note that it can sometimes be worthwhile to schedule in some break time, such as around holidays or in between books.
- Arranging a time and place to meet. One hour once a week should suffice. Ideally in a setting that would encourage round table discussion instead of a lecture or presentation. As such, a room with a large table and many chairs surrounding it works better than a lecture hall with all seats facing a front stage. Additionally, it is useful to have a large TV or screen in the room and a method to allow anyone in the group to easily cast their laptop screen to it, such as using a Chromecast or similar device.
- Sending reminders about the meetup. People get busy and even with the best of intentions will forget about the meeting. Sending out a simple reminder the day of or the day before drastically improves turnout.
- Arranging presenters for each meetup. When first getting things up and running, it may make sense for the facilitator to also be the sole presenter, but over time it is worthwhile for the facilitator to encourage members of the group to volunteer taking turns being the presenter because it puts less of a load on the facilitator, gives the group the opportunity to more fully learn the material (those who learn the material best are those who teach it), and ensures the long term success of the meetup because it doesn't heavily depend on any one person. Note that it's still worthwhile for the facilitator to take his or her turn as the presenter, as well. You should make yourself available to the presenters to help them come up with ideas for their presentations, as needed. Additionally, as the facilitator it is worthwhile to have at least a few thoughts put together of what could be presented at each meetup so that you could step in and present if the scheduled presenter is unable to make it.
- Coordinate the hand off with the next facilitator. When first getting things up and running, it may make sense to have a single person be the facilitator over the course of many books, but over time it is worthwhile to encourage other members of the group to take a turn at being the facilitator. This ensures stability of the group, since it doesn't heavily rely on any one single person. The ideal time to switch facilitators is as you're finishing one book and preparing to start another.
- Get feedback from the group. Regularly check in with the group and see how things are going. Get feedback and make changes and adjustments based off of their suggestions. Ultimately every group is different, and it is always best to tailor the experience accordingly.
The Presenter
The presenter's job is to help the group get the most out of what they're learning by coming up with a practice problem for the group to tackle.- Come up with a practice problem. As you're doing the reading for the upcoming meeting, take note of the points being taught and which of those points would make for good candidates to cover in a practice problem. Think of a problem that could cover the use of multiple points from the reading. Note that you don't need to exhaustively cover all points brought up in the reading. Just a handful will do. If the points that you would like to cover don't fit together nicely into a problem, then trying making two smaller problems. It's better to have two smaller practice problems than to try to shoehorn multiple unrelated elements into the same problem.
- Solve the practice problem once yourself before the meetup. This allows you to give some guidance on good ways to approach the problem as needed.
- Lead the discussion at the meetup. My suggested format is to start out with letting the group share points they found interesting from the reading, and/or share example code, then move in to tackling the practice problem via mob programming, followed by allowing the group to make suggestions of other things to test or experiment with in the code, and end with a few minutes for the facilitator to take care of any necessary points that need to be addressed.
- Present the practice problem in the meetup. I've found that taking a mob programming approach works well, where the presenter is at the keyboard and lets the group tell him or her what to type. In general, let the group guide the code, but feel free to give suggestions here and there.
- Invite further experimentation on the code. After the group has finished solving the practice problem, it is a perfect time to invite the group to give any suggestions of anything that they'd like to test out on the code that you now have up on screen. This give the group an opportunity to further experiment and play with the code and discover things that they didn't know.
- Publish a write up for the group to reference later. At minimum take the practice problem definition and the code generated from the mob programming session and publish the two in an article that the group can go back to and reference as need be. That being said, by all means feel free to take it further than that. Add explanations about how the code works or why to write the code the way that it is. Expand further on the problem. Show different ways that it could be solved. If you feel like it would be useful to the group, feel free to add it. And then publish it. While you could put it on an internal company wiki, I'd recommend against this unless it happens to contain private company information. Instead I'd recommend that the article be published as either a github gist, a medium.com article, a dev.to article, a blog post on your own personal blog, or any other public facing option. Why? Because it can prove useful in your future as a way to show a potential employer that you have knowledge of a topic.
