When I was writing Robust Python, I wanted to put an epigraph at the beginning of each chapter from various quotes that I found from around the web and from books that influenced me. My editor wisely steered me away from this idea, because it interrupted flow and it felt forced, but I always wanted to pay my dues to the works before me. Thus, I tried to cite as much as I could through footnotes to make sure I was crediting what came before me.
As I think about the next book I want to write, I wanted to take a second to look back at the books that influenced Robust Python. I’ll list each of the books that shaped how I think about software today and how they influenced my writing. If you liked Robust Python, you’ll probably be interested in the following works as well
Pragmatic Programmer
This is probably one of the first books that I recommend to anyone starting off in software engineering. There are a multitude of tips that have stayed with me through the years, such as focusing on data-driven configuration over code, tracer bullets, and design by contract. So much of the book is grounded in realism rather than lofty ideal software projects. I still pick this up from time to time to absorb the wisdom
The Cucumber Book
I have a whole chapter of Robust Python that focuses on behavior driven development, and I owe it to learning about it in this book. I love testing, and this taught me to open my eyes past the developer-led testing I was used to and start thinking about how to do acceptance testing.
Clean Code
I debated including Robert C. Martin in my book as a source of inspiration. I find his views lacking nuance and some of his community interactions troublesome. I won’t recommend his book any longer as I think our field has evolved past some of his ideas. However, he did introduce me to the idea of treating software development as a craft, and I do owe quite a bit to this book. I definitely tried to write Robust Python as a “How to write Clean Code in a Pythonic style in the 2020s”, so I can’t understate the influence in the beginning of my career.
Refactoring
This is more of a reference book than something you can read straight through, but I nonetheless read it from cover to cover early on in my career. It was a smorgasbord of tips and tricks for how to refactor your code without breaking functionality. It gave quality rationale all the way through of why you might want to do this, and it gave me a much better idea of what dependencies truly are.
Working Effectively with Legacy Code
While not the easiest of reads, this book shaped how I understood testing in relation to large codebases. To understand a codebase, you must be able to test it. To refactor a codebase, you must have tests to help you. I’d say this is a book more about testability than legacy codebases, but most of my career has been in legacy codebases, and this book gave me a great kickstart towards it.
Modern C++ Programming with Test Driven Development
A C++ book influenced my Python? You bet. I do C++ day to day, so a big part of how I design systems come from how I view statically-typed languages. However, this book gave me something different. I expected to read a book about C++ and TDD, but instead, it was a solid engineering book that used C++ and TDD as it’s vessel. I learned so much about good engineering; I wanted to replicate this feeling through Robust Python. You aren’t just learning Python, you’re learning good engineering practices with Python as a backdrop
Learn you a Haskell For Great Good
C++ wasn’t the only other programming language that influenced me; Haskell actually was a big player in that space too. I’m a programming language fan, but I hated Haskell in college. I just didn’t understand it.
Now, I utterly appreciate just how much a good type system can give you expressiveness and safety. A lot of Part 1 of my book is rooted in how I think about types, and that all came from this book.
Release It
This is another book that taught me solid engineering advice, and I am grateful for it. Focusing on the system design aspect of software development, it gave me an idea of how to design redundant systems, provide bulkheads and circuit-breakers, as well as learn how to degrade functionality gracefully.
This is a book about robustness in your deployment and you already know that robustness is near and dear to my heart
Domain Driven Design
I’ll be honest, I haven’t looked at this in earnest since my undergraduate days, and I definitely did not appreciate it at the time. However, so much of this book has bled into other resources that I revere that I can’t leave it off the list.
It addresses domain models and good abstractions, which I think are the lifeblood of good software design. It is on my list of books to definitely revisit
Design of Everyday Things
This book has nothing to do with software, but has everything to do with software. It’s so popular, that Lynn Root riffed on it during her PyCon 2024 talk.
It is one of the bibles of good design, and talks about how users interact with a system from a psychological point of view. I highly recommend it to anyone designing a UI or API (I used a lot of these ideas in my API design chapter)
Head First Design Patterns
When I was in my sophomore year of undergrad, I took a software design class. We were assigned two books: the GoF book and this one. Needless to say, Head First Design Patterns was the favorite of the two for the class.
Although it may seem simple and childish at first, it was remarkably effective at explaining concepts to me, and I still use it as a teaching aid for developers. I cite three different design patterns in Robust Python, and I still feel like design patterns are useful today, even if they don’t look anything like the original implementations
The Cathedral and Bazaar
At the heart of this essay, software architecture is equated with buildings. Do we have time to build a grandiose beautiful cathedral over 100 years from well-specified plans, or do we have to adapt and pivot as we build an ever changing bazaar, fulfilling the needs of the people?
This book introduced me to the idea of treating software design in a much more fluid manner (but not without abandon). It reinforced a kind of agility that I still carry with me today
Quality Software Management: Vol 1
This is another one that I haven’t touched since my collegiate days back when I thought I was going to be a software tester. I can’t speak much to most of the text, but Gerald Weinberg has one of my favorite quotes: “Quality is some value to some person”
This also introduced me to systems thinking where it might be that the best code to write is none at all and the the bug reports you find might have more to do with the culture and environment than the code itself.
How Google Tests Software
It’s easy to fall into the trap that you must act like Google in order to succeed. So many companies try to emulate the tech giant, but they only have a fraction of the scale and problems, and they miss the message.
Written by a former Florida Tech professor, I enjoyed reading the book to see how a larger company might have to deal with testing. The big takeaway was the amount of preventative, deliberate work that was done to avoid bugs in the first place, which greatly influenced Part IV of my book
I truly have stood on the shoulders of giants, and I’m leaving off plenty of essays, papers, PEPs and discussions that I’ve had. I hope that you take a look at least at one of these books if you haven’t before, and I hope your view on software craftsmanship is as transformed as mine was.
Pat Viafore 