A system that has shipped leaves behind more than a source tree: the structure that was chosen, the reasoning behind each decision, and the way that field actually operates according to its established standards. That part rarely lives in the code, and if nobody writes it down it disappears along with the project.
What each post contains
What the problem was and why it was hard. What the system that was built consisted of, how the pieces fit together, what technology went into them. The background needed to follow the field. How the industry solves the same problem, and under which standards and protocols. And finally a handful of principles that still hold up afterwards.
The emphasis is on principles and architecture, not step-by-step instructions. There are no performance numbers either: a figure from one particular run means very little on its own, whereas the way a system is organised is something you can carry into the next project.
Who this is for
For the people who worked on these systems, as a shared record. And for anyone starting out in one of these fields — the background and industry-standards sections are written to stand on their own, without any knowledge of the original project.
On terminology
Technical terms are used in their standard English form, with a short explanation at first mention where the concept is not obvious.