Skill Zero: Test Driven Development
Small Batches was probably the best tech podcast I discovered in 2024. Among all the incredible episodes Adam Hawkins recorded in the last couple years, I consider Episode 107 (Skill Zero: Test Driven Development) a masterpiece which deserves to be re-listened from time to time.
Small Batches podcast, Episode 107, from April 22, 2024.
Adam basically summarises, in a 13-minutes episode, all the best practices I took (at least) ten years to learn.
No matter how many times I listen to it, this sequence is always especially delightful to me:
• Adam pulls a new ticket from the queue and prepares for the work
• Adam sees this is a large change, so he ponders a few ideas before continuing
• He knows the changes cannot happen all at once, so he prepares a sequence of small incremental changes
• The strategy is any change is always the same: PDCA: Plan, Do, Check, Act guided by Red-Green-Refactor
• The plan is come up with an implementation. Do: write the test, then code
• Check is always the same: are the tests passing? If not, keep working, If so, refactor
• Adam does not commit to an implementation at the beginning. Instead he tries a few alternatives to converge on best fit. Experimental code is discarded with git reset commands
• When Adam sees the implementation and the incremental sequence of changes, then the real work begins
• First the test, red test suite, the then code, red test suite, fix the first failure, green test suite, continue
• Red-green-refactor
• Commits are surgical and clearly thought out
• Net-new and refactors are clearly delineated
• Commits stack on top of each other directly in master
• Clearly evident in Github with green checkmarks beside each one
• Code is ready for production
This flow describes exactly what Bruno Pastre and I consider a perfect workday.
We've been pair-programming, on a daily basis, for more than one year now, and we always try to apply the steps described by Adam.
Yes, we completely discard experimental code.
We do red-green-refactor, by the book.
We invest a reasonable amount of time on commit messages.
We wait for a green pipeline before moving to the next task.
The result? A steady stream of well‑tested, production‑ready changes that feel almost effortless.
Test-Driven Development is, for sure, very hard to start. However, once we get used to it, it's nearly impossible to imagine stopping.
As Adam says:
There is a clear marker in history: before TDD and after TDD.
So, in this episode, I’ll tell you why I think TDD is skill zero for software engineers.
Enjoy it!
