It runs from installation to point of sale by way of models, server-side logic, module data, debugging, views, access security, translations, automation, web development, the frontend library, automated tests, remote calls and performance. This is the sixth edition of a series that started a decade ago, and it shows in a good way: the chapters are ordered by how you work, not by how the product is built.
What I took from it
The module data chapter changed how I work the most. External identifiers, flags that keep a record from being overwritten on every update, loading through files instead of through code. The rule I kept is that before programming something it is worth asking whether it can be declared: declared data gets versioned, reviewed and survives an upgrade, while programmed data has to be retested every time.
The access security chapter left me an order for reviewing somebody else's module. First who can see and do what, then the record-level rules, and only at the end the logic. When something behaves oddly in a multi-company installation, the cause sits in those first two layers far more often than in the code.
And the performance chapter, together with the testing one, is what turns a module into something maintainable: measure before optimising, and leave behind a test that fails when somebody breaks what was expensive to fix.
What I left out
Reading it straight through, which makes no sense for a cookbook, and the web frontend chapters, which are for people building custom screens. But the real gap is elsewhere and deserves naming: a cookbook teaches you to build on today's version and says nothing about what becomes of that next year. What breaks on an upgrade, which third-party module lost its maintainer, which hook disappeared between one version and the next — none of that is here, nor could it be, and it is precisely what I am most often asked to sort out.