Run a better book club

What I’d do if i were to run it (and maybe if i run it, i’ll just follow this):

1. Be clear about the PURPOSE. AKA “Start with Why”
   1. To level up how we, as engineers, design, debug, and reason about large-scale systems. Not just to build them, but to build them to be efficient, sustainable, and easy to reason about.
   2. DDIA gives us a shared language for thinking about tradeoffs: consistency vs. availability, latency vs. durability, fanout vs. cost, local correctness vs. global truth.
   3. The goal isn’t to memorize theory, it’s to connect the dots between the systems we already have (medium2, Conduit, EMR, DynamoDB, Recs, whatever, i’m just spitting out buzzwords), the design decisions that got us here, and how to level that up.
2. Set a clear, non-threatening schedule, that respects everyone’s time. Maybe 6 sessions, biweekly, 60 minute sessions each. I think DDIA is 12 chapters, so just 2 chapters every 2 weeks.
3. Define what the sessions are. What i liked in the past:
   1. 5m: Ice breaker / share-out: What was one a-ha moment, observation, or thing that triggered you when you compare what you read to what we have in production?
   2. 30m: breakouts (it’s hard to have a meaningful discussion with 8+ people) around some set of possible prompts. They should ALWAYS include the final ”… cool story bro, and HMW apply this at Medium? Do you see any anti-patterns or opportunities anywhere? What might the impact be if we DID change this? What would the tradeoffs be?” <— that gets them focused and gets them working on collective problem solving towards a shared purpose
   3. 10m: Come back together, and each group does a shareout of what they learned, ideas they came up with, and interesting tradeoff discussions
   4. 5m: closer: Reflection (opposite of ice breaker) - what’s one thing i learned, what’s one takeaway or idea i think i may use in my work going forward, what’s one idea i want to take to my team, what’s one thing i learned that I wish I knew before?
      1. “What’s something that struck you from these chapters?” (keep it more general)
   5. Have a note taker that can capture and synthesize and share this out (anonymously, so folks feel safe to be ignorant)

As part of the purpose, I like to lay out more of the why at a meta-level, so people can read the book with these things in mind.

GOALS:

“By the time we’re done with this book, I hope you can look back and agree on at least some of the following:”

• I have a stronger mental model how how data should move through Medium, and what it should cost
• I have a deeper systems intuition for understanding and debugging complex systems
• I have a better design vocabulary and understand more patterns and best practices, so that i can better design systems and better communicate these designs
• I am more cost-aware of the tradeoffs of my designs, and can better reason about how to explore various tradeoffs and communicate these tradeoffs
• I feel an increased sense of ownership and stewardship of our codebase and costs

something like that

At Dropbox we had a slack channel with a weekly prompt “lolz what dumb thing did we do in the ios codebase that we should have known better” (not worded as sharply of course, but basically that). it made it safer for people to point out the obvious dumb stuff

And at the end, you could have some folks (if motivated) to do broader share-outs at eng all hands, a presentation of DDIA concepts and how they may apply… or better… how have SINCE applied them for clear wins (for even MORE amplified learning)