A jargon-free introduction to data models and data modeling — what a data model actually is, how they’re typically represented (ER diagrams, relational schemas, JSON structures, dimensional models), and why deciding the shape of your data before writing the code that manipulates it is usually the cheapest work you’ll do all quarter.
The question is almost never ‘how do we add this method to the SDK?’ — it’s ‘where should this capability live?’ A companion to the SDK fundamentals post, covering capability-first SDK design (with the caller-sketch discipline as the practice), the five-way routing framework for new capability requests (pure SDK / additive API change / new endpoint / new API service / push down for generation), signals for extending an existing API vs. creating a new one (with Stripe Terminal and AWS Lambda as named examples), and the version-coordination process when a capability requires changes on both sides.
Unit tests that break every time you refactor are describing the implementation, not the behavior. A senior engineer’s playbook for writing black-box tests that survive.
Four voices argue about unit tests. The debate dissolves once you separate coverage-as-target from coverage-as-detector, with testability as the real prize.
Not a catalog of the Gang of Four patterns — an argument for why they’re foundational. Design patterns are a shared vocabulary that lets you read a codebase’s architectural intent from the names alone, and the value of that shared language transcends any specific programming language.