Conclusion
If you've come this far, thank you. Even if you don't agree with everything I've written, I hope this book has made you think, and maybe even unseated some long-held Django orthodoxies. As I said in the introduction, there's no need to adopt every suggestion in this book. If there's an idea you like, take it and see how it works in your codebase.
The perspective outlined here is as much a philosophy as a set of concrete guidelines. By putting simplicity at the forefront of our thinking, and dismissing patterns that impose structure without genuine benefit, we can put in place a straightforward set of guardrails, and sketch out a "pit of success" that most problems neatly fall into. Not everything will work with this approach, but I'd say 90% or even 95% of features in most Django codebases I've ever worked on would benefit from some or all of these ideas.
The most important learning in any software engineer's career is that everything is a trade-off: there are no panaceas, and what works well for one particular codebase being worked on by one particular team might not work for another. Take everything you read with a large pinch of salt, and think through all of the implications before you proceed.
One of the huge benefits of working at an agency is that I get to see these trade-offs at scale: most product companies have just one codebase (or maybe a small handful), but we need to maintain dozens, all with different goals and different approaches and teams with different skill levels and specialities. The patterns that stick around are the ones that apply broadly and make life better for everyone, and those are the patterns expressed in this book.
This book reflects what has worked for me and my colleagues so far, but it is not the last word. If you adopt any of these approaches, or if you find places where they break down, please let me know. Shared experience, rough edges and all, is the only way we end up with patterns that really deserve to be called common practice rather than personal preference.