The audiobook for The Pragmatic Programmer is everything that an audiobook, and especially everything that a technical audiobook, should be. I love to listen to stuff about software, but a lot of it doesn't suit the medium well. A lot of thought went into this: the narrator is excellent, some passages are read by the authors, and the code snippets are adapted to the audio format with good judgment.
Satisfyingly, this is not just an authorial but a programming success; the book itself is used as a case study in how to use text as a single source of truth, how to parallelize parallel problems, and how to do the reasonable thing even if it annoys your publisher.
It's easily the single best technical audiobook experience of my life.
The content is also excellent: this is a true revision of the original. It mixes "wisdom of the ancients" and "current expertise" far better than I expected it to. (Not all rereleased classics of programming literature hold up.)
I endorse most, by far, of what's in the book. Two quick points of disagreement:
pizza
, not thing_ordered_on_thursday
or thursday_pizza
. In the buyer
/user
case, I fear that the code might change so that a buyer
is also a shipping recipient, a notification recipient, or something else. Many problems are caused by names that are not descriptive enough, but many are also caused by things named according to accidents of their original context, not their real essences.[1][1] There's a counterargument here that roughly goes: if a thing takes on other roles, it will be in a different bounded context, so the other name will be for a legitimately different object in a different context, and the original (more specific--e.g., "buyer") name will after all have been apt. Perhaps such an argument is correct, but that's not the argument the authors give.