A list containing books (articles etc) that each member should read.
I think so.
RequiredI am not sure if “required” is the right concept, “strongly encouraged”, incentive linked or similar is perhaps enough emphasis.
Also “Should read” does not mean all books have to have been read before joining the team, more a list of books to read while in the team.
WhyTo gather a common basis for discussions and choices within the team. To grow the competence of the team and ensure more correct decisions by having more relevant information. By reading and updating themselves the team is exposed to new ideas and can discuss and grow their understanding of this at work.
Unanimous agreementIt should not be requirement to agree with the contents and aim of every book, however it should be a requirement to have read it so that it can be discussed. In favour or quite the opposite only adds to the discussion quality.
Never read them allYou should never be finished with the the “Reading list”. If the list is too short and you have read all of them (or even based it on your own previously read books) then you become complacent and not open to further competences and ideas.
List evolutionThe list should grow continuously and irrelevant/outdated items should be pruned from the list. The list should perhaps be put into sections, and also prioritised if large.
No readingTeam members that does not read nor update themselves in other ways, do you want them in your team? They may be great right now, but will they stay that way? I am always wary of people that do no expose themselves to new thinking. Can I really trust their convictions on a solution for an issue is the most prudent solution?
Some people are very productive and valuable without updating themselves. It is rare and uncommon however.
Pretend readersSome colleagues will perhaps say they have read or reading books from the list, but have no intention of reading anything. There should probably not be any need to quiz them to ensure knowledge, in due time their evaporating competences will show their true colours anyway.
Book qualificationHow do you select books on the list? Initially perhaps senior team members, architects etc could select a small selection of relevant books. But as the team grows the list should probably be suggested and voted on by the whole team to ensure common consensus and introduce newer not mainstream suggestions.
Reading speedAn interesting issue would be how to ensure that people do actively read. That is not just up to the individual, but should perhaps be part of incentives, part of project cost and time allocations. That is a harder sell, but will pay itself over time.
Some people though can read fast others not, some have no life and can read all weekend, others have 15 kids and no spare time. As long as they “are” reading I would be happy. 1 book per year or 10, it is all good.
Not related titlesPerhaps the list could contain subjects not related to the specific teams function. Fictional, philosophical books? Perhaps not.
My reading listIf I were to list books I would probably include many items I have not read, just skimmed or even agree with. I also do not have a great amount of time to read books either, but I force myself. I get the odd for free for reviewing, buy a few related to projects and a few hobby subjects, totaling 4-8 per year.
To list suggestions for teams similar to mine (enterprise Java, finance sector):
- Design patterns (Gamma, Helm, Johnson, Vlissides)
- Patterns of Enterprise Application Architecture (Fowler)
- Enterprise Integration Patterns (Hohpe, Woolf)
- Mythical Man Month (Brooks)
- Peopleware (DeMarco, Lister)
- Agile Project Management With Scrum (Schwaber)
- Succeeding with Agile (Cohn)
- Kanban (Anderson)
- Kanban and Scrum (Kniberg)
- Clean Code (Martin)
- Working Effectively with Legacy Code (Feathers)
- Effective Java (Bloch)
- Java Concurrency in Practice (Goetz)
- ReWork (Fried, Heinemeier Hansson)
- 97 Things Every Programmer Should Know (Henney)
- REST in Practice (Webber, Parastatidis, Robinson)
- Seven Languages in Seven Weeks (Tate)
- UML 2 for Dummies (Chonoles)
Any comments or suggestions are welcom.