Reading the Clean Code book, as for reading any book really, is not just about reading and understanding. It is also about reflecting on what is stated and translate it into your own context and experience. I hope that these questions will help you do this.  

In a previous post entry I wrote about my idea of starting a Clean Code study circle at work. In this blog post I will collect an overview of the book as we continue our study circle providing links to blog post containing questions for each chapter. I've also posted some guidelines and recommendations for others who are thinking of starting a study circle. I will be updating the list below with links as we go along with our study circle at Admeta during 2009.

Study Questions chapter overview

1. Clean Code: questions
2. Meaningful names: questions
3. Functions: questions
4. Comments: questions
5. Formatting: questions
6. Objects and Data Structures
7. Error Handling
8. Boundaries
9. Unit Tests
10. Classes
11. Systems
12. Emergence
13. Concurrency
14. Successive Refinement
15. JUnit Internals
16. Refactoring Serial Date

Some Guidelines for Starting a Study Circle

If you are thinking of starting a study circle at work, here’s a couple of practical advises based upon our experience:

1. The topics in each chapter can potentially lead to discussion that lasts for days... But try to limit yourself to the time set out for it. The meetings is not necessarily about reaching a final agreement of every discussion. Instead, look at is as the beginning of a journey to some kind of agreement of a mutual understanding of what clean code is.
   
   
2. During the hour, we summarize each sub chapter. I.e. some volunteer person for each subchapter summarizes in his own word briefly and objectively what was written. Once done with this, the same person gets to be the first to reflect upon the content. A discussion can follow afterwards.
   
   For us, such a summary/discussion of the chapter would take more than an hour (in both groups). So it is a good idea to tell people in advance what subchapters they think should be focused on in each chapter. Start with these subchapters when you meet!
   
   Most likely, you will not have time to discuss the questions. But you may sneak a question in at a sub chapter discussion.
   
   
3. As a follow up to the meeting, use some kind of survey tool to poll questions discussed in the meetings. This way you will actually get a statistical backing up of what people think based not only by those who are the most eloquent with words.
   
   I tried out using SharePoint surveys but I don’t like the tool. (I might come back with a little blog post rant on this…)
   
   
4. If there are many developers, split the group into smaller groups. It is easier for all people to get a chance to say something if the groups are smaller. The person who set up the group will participate in both groups and act as the meeting coordinator and bridge between the two groups.
   
   If several groups are used, I think it is a good idea to rotate the people in it every other or third meeting. Everyone should really know everyone in good working teams.