How to run a Developer Book Study

Have you seen "Everything I Know" from Buckminster Fuller? He recorded 42 hours of lectures detailing his entire life's work. I tried to read the transcript but it was unbearable. More limited in scope is my "Everything I Know about Developer Book Studies". It may not be better than Bucky's, but it's certainly easier to get through. So here are my experiences from doing a few book clubs a year over the last 3 years.

Picking a Book
This is way harder than you'd think. Creating a web survey for your team or devising elaborate instant run off voting schemes aren't worth the effort. Better to gather several ideas and then let one person decide... naturally that person is the one organizing the book study in first place.

But picking a good book is still hard. Don't trust Amazon ratings. Many of the ratings are given by people compensated to give a review. There's a lot of publishers handing out free books in exchange for public reviews, so 4 stars doesn't mean a whole lot. Jolt Awards on the other hand have proven to be a very reliable source of good books. Even then, it can be a crap shoot. "The Pragmatic Programmer", for instance, is a great book but we had a terrible time finding meaningful conversation around it. Perhaps some books are just meant to be read alone.

Finally, don't pick anything too long. A lot of people (me included) have a hard time not reading every page of a book. In a larger group you'll surely have a few. Dragging a book club out over several months saps your energy. Low 300 pages is my limit. The bigger font the more better, too!

Creating an Invite List
Do you invite everyone on the team? Everyone in the company? The remote office? Contractors? It depends on what you're trying to accomplish with the book study. A team only book club is good if you're reading a book that specifically applies to your project, while an entire company book club is good to promote practices across teams. Want to jumpstart agile adoption with a book study? Invite the team only so you can discuss specific practices to start using that make sense for you. Want to upgrade your standard coding practices by reading Clean Code or Effective Java? Invite the entire company, because quality discussions don't depend on a specific team context.

Remote employees are hard. Conference call etiquette always seems to break down. It's most painful for the remote person, so he or she needs to be especially motivated to benefit.

Having several people remote can work. We did a Design Patterns study and included a team from a different company. We agreed not to discuss work specifics and it turned out pretty well. We read Head First Design Patterns and GoF at the same time, and one person from each site presented on the same pattern from the different texts. The room with more people did dominate the conversation though.

As for contractors, I like to invite them and explain the time is non billable. Few accept but I feel it's a nice gesture. Does that sound condescending? It's not meant to be.

Choosing a Format
The format is one of the most important decisions, and different books require different formats. Soft skill books, especially agile, don't need much structure. Everyone has an opinion and everyone can generally contribute to the discussion (not always a good thing). Technical books need more structure. We did Java Concurrency in Practice and settled on a format where each person is assigned a week, and that person presents back to the group as if they hadn't read the chapter (which they had in fact read). No one was an expert on concurrency, so without the format we had nothing to say. With the format, even people who hadn't had the time to read that week benefited.

Try to have a format that produces decisions. "We will start test driven development" or "We will document monitoring concerns in designs". Without action after the book study you're just sitting around talking. Try to use what you learn at work with specific actions and decisions. Writing all your decisions and recommendations down can help you plan your course of action after the study is over. Don't bother taking minutes though; it's unlikely that anybody wants to read them.

Also, it's nice to give everyone something to take away. If it's your turn to lead then have a 2 page handout ready with your material or your code samples. Handouts are much better than slides because they can eventually be transformed into blog posts or internal trainings.

A final bit of logistics: schedule the meeting for 1 hour, the room for 1.5 hours, and try to finish in 45 minutes. If no one has anything to say then cut losses and run. If the discussion is productive then stay a little late.

Reading the Book Correctly
I like to set an aggressive schedule to keep the study under a two month span. Any more and you get burned out and bored. Once a week for two months is a lot. Our Release It! study did four every-other-week meetings and worked great. Keep it short.

Read with a highlighter. Highlighting text forces you to read the important passages twice, making them more memorable. You'll remember a book better if you've highlighted it, it's easier to come back and find passages later if they are marked, and it's easier to gather up your notes if the book is marked up. And bringing a written set of notes to a free-form session is very helpful, it helps keep the conversation on the most important topics.

As for the pace, I have two bits of advice:
1. Don't read ahead; you'll forget the material by the time the sessions come around.
2. Read the entire book ahead of time; you'll have better discussions because you understand the book's entire context and the pressure will be off to complete some sort of weekly reading schedule.
"Do I contradict myself? Very well, then I contradict myself, I am large, I contain multitudes." -Walt Whitman. See? My copy of Song of Myself was highlighted, so I could easily find that passage! (OK, I admit I googled it).

Promoting the Event
Showing the value of the book club to the other developers and managers can build interest and get more participants in the next club. Let others know what they missed by posting your notes on your blog or wiki, or holda training session on the book content at the end of the study.

I like to let managers know who is and isn't participating. If some teams aren't present in the studies then the managers can apply pressure to get more people involved. Being known as the guy who organized the book club doesn't hurt your reputation either.

Lastly, ask to be reimbursed for the books. It can't hurt. My employers have always been happy to buy books, I'm surprised when people are afraid to ask.

Take a break
So your bookclub was awesome... now don't do it again! Give yourself some time to recharge your batteries and implement all the great ideas. It'll also give you time to email me with your lessons learned. I'd love to hear them.