Code, data structures, and system design

October 2021

Code

Python is among the most useful programming languages. Why? It's easy to write. Its creator's perspective on what code is for:

“You primarily write your code to communicate with other coders, and, to a lesser extent, to impose your will on the computer.” — Guido van Rossum

Data structures

From The Mythical Man Month by Fred Brooks:

Representation Is the Essence of Programming

Beyond craftsmanship lies invention, and it is here that lean, spare, fast programs are born. Almost always these are the result of strategic breakthrough rather than tactical cleverness. Sometimes the strategic breakthrough will be a new algorithm, such as the Cooley-Tukey Fast Fourier Transform or the substitution of an n log n sort for an n^2 set of comparisons.

Much more often, strategic breakthrough will come from redoing the representation of the data or tables. This is where the heart of a program lies. Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious.

From an email written by Linus Torvalds

I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

System Design

Conway's Law

The structure of organizations is tightly coupled to the systems it ships. This is known as "Conway's Law":

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." (reference), originally from "How Do Committees Invent?"

Seems like Bezos knew this - sounds a lot like The algorithm and the 5 ideas

Stephen Wolfram on the biggest challenge of building software

"The hardest thing, the thing that is most intellectually demanding, is overall design…in my view…kind of the "functional design" of the system. How do you make the right decisions that are going to be sort of the bedrock on which you construct the system? How do you build things that you're not going to regret later?" (link)

Werner Vogel's guidelines for building cloud software

Internet Technology Architecture

  • Use late binding
  • Put everything in logs
  • Don't think in single failures
  • Architect with cost in mind
  • Protecting your customer is the first priority
  • In production, deploy to at least 2 AZS
  • Build, test, integrate, and deploy continuously
  • Entir non sunt mulitpilcanda prakter necessitiatem (Occam's Razor)
  • Don't treat failure as an exception
  • Integrate security into your application from the ground up
  • Automate your application and processes; let business levers control the system
  • Assume nothing
  • Inspect the whole distribution
  • Instrument everything, all the time
  • Decompose into small, loosely coupled, stateless building blocks

6 rules for building APIs

  1. APIs are forever
  2. Never break backward compatibility
  3. Work backwards from the customer use case
  4. Create APIs with explicit and well-documented failure modes
  5. Create APIs that are self-describing and have a clear, specific purpose
  6. Avoid leaking implementation details at all costs (customers will build on this information, creating stickiness)