Tips for starting and running a Programmer's Book Club

Question

I've been toying with the idea of starting a reading group at work. We'd pick a book like The Pragmatic Programmer or Practices of an Agile Developer, hopefully get the company to buy us copies (or just get our own), read a chapter or two a week and then get together at the beginning or end of the week to discuss the chapter and the practice(s) discussed within. People could share personal experiences or ask questions if they are new to the practice.

Does anybody have any personal experience with this or ideas to offer? How did you get it started? How did you keep it interesting?

Answer 1

My first thought would be to get books in PDF format: it's much easier to have the opened book on one screen while working on the next than it is to glance from book to screen and keep the book weighted down so the pages don't flip.

Answer 2

At my company we watch semi-educational videos on Fridays. My only contribution is that free food (we get pizza usually) will increase your numbers, especially because developers will find themselves getting used to not making lunch one day a week. I can't speak to how it will affect quality of discussions though.

Answer 3

1. Make sure to read these tips (from Joshua Kerievsky) on study groups: http://www.industriallogic.com/papers/learning.html

2. Study groups are one of the best (and easiest) things a company can do for its team. However, if there is any concern that the attendees are "wasting" their time, it might help to host the meeting over lunchtime (i.e. brownbag lunch sessions). If the study group is successful, the conversation should shift around the room, and everyone has time to eat their lunch in the usual time frame.

3. Don't worry if the group starts small. If you show benefit and enthusiasm for the attending members, others will come. (and you won't care much anyway if the group is enjoying it)

4. Find ways to apply the study group lessons to the group's daily work and vice-versa. For example, use code samples from your actual projects and try to apply lessons from the book. Appoint a different presenter each week that can look for examples to present with the next meeting. -- This helps reinforce the benefit of the group as well.

5. Create a place to share the group's resources, findings, and conversations. This might be in the company intranet, using a (free) wiki host, blog, etc. The point is encouraging and sharing what you find. This can also help show others what you're learning and doing.

6. Most importantly, continue to foster a culture where learning is important. In a healthy environment, all members want to grow, improve, and contribute. It may seem obvious, but never criticize comments or any participation in the meeting (don't assume there is one right way). If disagreement arises, it would be great to include the different approaches in your study group (present both sides, show advantages, disadvantages of each, don't try to reach one conclusion for all cases). This is another important reason to rotate the moderator each week.

Answer 4

I recently started a book club at my office. We're working through The Elements of Computing Systems. At the end of it, we should each of an OS that runs programs that we write for it. I really like this type of book club because you actually produce code along the way. So, we can compare implementations and discuss problems.

To get started, I just put the idea out there that we should do a book club for this specific book. Maintaining interest isn't as hard if everyone enjoys the topic.

Answer 5

I organize several book clubs and have the exact same idea right now-- a developer oriented book club. Here is my amazon list of candidate books that could fit the typical book club format. Most people that will be willing to go to a book club have already been to other book clubs and know the routine. If you don't pick a book that fits with those expectations, the discussion might not be much about the book. The social script for a book club is to wander off topic as fast as possible if the book doesn't lend itself to discussion.

Ideally, a book-club-book should be something that can be read cover to cover without firing up an IDE or stopping to digest and probably not too much code in it. I can't open The Pragmatic Programmer to look, but this looks in the right ballpark. People tend to read the book for the book club in a big hurry a day or three before the event. C++ in 21 days is not a good candidate.

Book club discussions favor lower density, shorter books. A heavy algortims book that covers the difference between bubble sorts isn't a good choice, but if you really, really wanted to do something of this sort, then stick to a chapter or two. Still, if the content is cut and dried facts, there may not be much to discuss. So we read a chapter together and we now grok bubble sorts and alternative sort algorithms. What's to discuss?

Book club discussions tend to run long. Lunch time work work as well as a weekend. If what I'm saying sounds all off key, what you may have had in mind is a brown-bag presentation, where attendees might read something to prepare, everyone attends at lunch and one person lectures for an hour with Q&A at the end. The brown-bag format, imho, would work very well for a code centric book, like Clean Code.