Tidy First?
Small Changes, Big Impact.
Hello! I recently finished reading Tidy First? by . The book presents many actionable ideas, which I thought would be interesting to discuss in The Coder Cafe. Note that this post aims to highlight the points I found most interesting for me, making it entirely subjective—others may have chosen different aspects to focus on.
What is Tidy First? About
Tidy First? focuses on software design and the concept of tidying, which is introduced as:
Tidying are a subset of refactorings. Tidying are the cute, fuzzy little refactorings that nobody could possibly hate on. “Refactoring” took fatal damage when folks started using it to refer to long pauses in feature development.
This concept resonates with me, and I fully agree with the author’s perspective. Indeed, refactoring can sometimes carry a negative connotation, especially in fast-paced environments where short-term delivery is prioritized over long-term maintainability1. For example, justifying the need for refactoring during sprint planning—even with the argument that it will make future changes easier—can be a tough sell. That’s why the idea of a category of refactoring that is small yet impactful makes complete sense. I was already sold on the book’s premise from the first chapter.
Tidy First? is divided into three main sections:
Actionable tidyings: A collection of small, quick refactorings, each explained in its own chapter.
The tidying process: Guidance on when and how to tidy our code.
Theory: Fundamental principles behind software design, such as coupling and cohesion.
Key Takeaways
Normalize Symmetries
Code grows organically. Some folks use “organic” as a pejorative. That makes no sense to me. We can’t possibly write all the code we’ll ever need all at once.
I highlighted this part because I often hear the same argument, and I have to admit I used to associate “organic growth“ with a somewhat negative meaning—something that keeps expanding without taking time to refactor. However, the author made me reconsider my opinion.
In growing organically, the same problem may be solved differently at different times or by different people. That’s okay, but it makes for difficult reading. As a reader, you’d like consistency. […] Pick a way. Convert one of the variants into that way.
I completely share the author’s opinion; I even consider myself obsessed with consistency (probably a bit too much). If there’s already one way to do something in a codebase, we should introduce a new variant only if there’s a very good reason to. If a term is described in a specific manner, let’s keep it that way. Even if a word is spelled in a certain way, we should either stick with it or decide to change all the previous occurrences (e.g., “cfg“ vs. “config“, “log_in“ vs. “login“). Consistency in a codebase is fundamental.
Reading Order
Reorder the code in the file in the order in which a reader […] would prefer to encounter it.
A simple yet effective rule for organizing code. For example, in a previous company, we ordered Java methods so that instance methods appeared before static methods, even if some static methods were used only in a single instance method. This was the convention, but in many cases, it made the code less intuitive to read. Grouping related elements together improves readability.
In Go, for instance, reading order often takes precedence over rigid conventions—constants might be placed in the middle of a file if they logically belong here (an example in Go’s internal library). This aligns with another quote from Tidy First?:
Reorder the code so the elements you need to change are adjacent. Cohesion order works for routines in a file: if two routines are coupled, put them next to each other.
Explaining Variables
In this section, Kent Beck gives us a simple but effective tip. Instead of writing:
return new Point(
// Long expression,
// Another long expression
)We should rather extract subexpressions into variables (named after the intention of the expression):
x := // Long expression
y := // Another long expression
return new Point(x, y)I know at least one ex-colleague who would disagree, arguing that variables should be inlined if they are used only once. But I follow the author’s reasoning here: variables don’t need to exist solely for reuse. If naming a variable improves clarity, it’s totally worth it.
Chunk Statements
You’re reading a big chunk of code and you realize, “Oh, this part does this and then that part does that.“ Put a blank line between the parts.
Another straightforward yet efficient piece of advice. What I particularly like about this is how it contrasts with other traditional refactoring advice. Books like Clean Code emphasize breaking functions down so they “do one thing"—which is fair in theory but often requires more effort and time. In contrast, Tidy First? suggests lightweight improvements that don’t demand rewriting entire functions but simply introduce a blank line.
I once read that code should be structured like paragraphs. In technical writing, each paragraph should focus on a single idea. That’s exactly the same principle here.
Explaining Comments
Write down [comments] only what wasn’t obvious from the code. Put yourself in the place of the future reader, or yourself 15 minutes ago. What is it that you would have liked to have known?
A solid guideline. Often, when we write code, we’re so immersed in the context that we don’t realize what might not be obvious. That’s also one reason code reviews are helpful, as the reviewer can provide their own perspective on what is unclear.
Yet, if we struggle to understand a piece of code that we haven’t written (or that we wrote months ago) and finally figure it out, it’s worth taking a moment to add the comment we wish had been there in the first place.
Software Design
Now I can say what I mean by “software design”: beneficially relating elements. What is design? It’s the elements, their relationships, and the benefits derived from those relationships.
I keep a personal dictionary of concept definitions, and I’ve added a new entry for “software design”. It’s simple, clear, and captures the essence perfectly. I don’t have anything to add, I loved it.
Coupling
The word “coupling” has lost its meaning over time, coming to mean any relationship between elements in a system. “This service is coupled with that service”—okay, but how? With respect to what changes? It’s not enough to know that one service invokes another; we need to know what changes to one service would require changes to the other.
I already discussed the concept of coupling in a previous post, where I outlined different types, such as control coupling (when one component controls another’s behavior) and temporal coupling (when two components need to be active at the same time). These are just examples, but they illustrate how “coupling” is often too vague. Understanding the specific ways in which two elements are coupled helps us build better mental models of a codebase or s system architecture.
Conclusion
To summarize, I really enjoyed reading Tidy First?. I think the emphasis on small, practical improvements rather than large-scale refactoring is a great idea, and I highly recommend this book.
I also believe that tidying should be a mindset when working on a large codebase—it’s not just about occasional cleanups but about making small, continuous improvements that keep the code easier to read and maintain over time.
Kent Beck mentioned that this is the first in a series, so I’m really looking forward to the next one.
💬 Have you read this book? Are there any additional takeaways you would have highlighted?
📚 Resources
More From the Software Engineering Category
Explore Further
- ’s Substack publication: