Book Club: Tidy First?

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.


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?


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.


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.