Book Club: Tidy First?
Updated: February 2024
I love short engineering books. Software engineering is so complex by default that big books tend to feel like they multiply that complexity rather than distill. Short books raise a couple ideas and let you simmer. My favorite by far is “A Philosophy of Software Design” which gets a notable mention in the references section of this book. The two books are definitely cut from the same cloth, though this one is less self-contained.
”Tidy First?” Asks some thought-provoking questions and provides valuable examples, both tactical and strategic. However the book’s segregated structure diminishes its impact. The three parts are closely interconnected and would be better presented in a more integrated manner. The book talks about how these are the “what”, “how”, “when” and the “why” of tidyings. As I read through the book, I found myself flipping between sections to make connections.
But, that’s the that’s the power of a small book. The information is all there within 100 pages. But you do need to read the whole thing before starting to draw conclusions. Also the book punts several issues to future books in the series, which leaves the reader in the lurch if it’s a compelling direction (the next books are about relationships between developers, which would help follow up on his code review suggestions, and how technology and business can work together which would empower some of the chapters that define the cost of tech debt).
So, given that it’s a very slim book, I wouldn’t suggest a step by step procedural book club, but rather use it as a starting point to talk through engineering philosophy and process after folks have read the whole book. If you want your team to have some conversations about how light code improvements (“Tidyings”) can become part of your processes, this book could be the spark.
Discussion Guide
First, read the whole book. Again, it’s short. Shouldn’t take more than a couple of hours, highlight things that jump out as you go.
Session 1: Defining Tidying for Our Team
Referring to the “what” examples from Part 1. Goal here is to get on the same page around what this work might look like on your team, in terms of what code should be the focus, and what kinda patterns should be prioritized.
Discussion
- For your team, what is tidying and what isn’t?
- How do we determine the difference between behavior change vs. code structure?
- Do all tidings have to be invisible to our customers?
- When does a Tidying become more than a Tidying?
- What are patterns that we should target with our initial Tidying focus?
- How can we keep a living list of current patterns up to date for future use?
Session 2: Fostering a Culture of Tidying
Building on the “how” and “when” ideas from Part 2. Given that you now have a sense of what these things might be, how should they fit into your team’s processes and work tracking systems? There’s a great line in the book about “I want do do some work, but didn’t want to puck up a big thing.” How to enable that feeling on your team?
Discussion
- Is he right that code review on small PRs gets stuck in the weeds and is unnecessary for Tidying?
- As a team how can you encourage Tidying work?
- How can your team experiment with process changes?
- How to build up a list of “Tidying tasks” that can be shared?
- How to make working on them enjoyable?
- How is Tidying work recognized?
Session 3: Is it working?
Run this after you’ve been trying the stuff for a few cycles and have meaningful experience. Referring to the “why” ideas from Part 3 to see which ones feel relevant can help talk through the processes successes and struggles.
Discussion
- Where have the Tidying changes been focused?
- What have we learned about making these kind of changes?
- Should we keep doing them?
- What should we change in how we focus on them?
- Which of the “why’s” resonates the most, and should we adjust to focus on that reason more specifically?
Maybe this helps, maybe not. But I do think that it’s important for engineering teams to talk more about “engineering” than the current status quo. And it’s a rare to find books that can provide a bit of a nudge without saying too much.