The developer's great book

1.1 Everything is a number

A heads-up: this is the most low-level passage in the book, and that is on purpose. Don't try to memorize the bits, aim for intuition: understanding why the machine can only store 0s and 1s. Once that foundation is set, the rest of the book flows down from it.

A bit is a slot worth 0 or 1, like a switch off or on: the only thing the machine can physically hold. You group them by eight (a byte: eight cells with two choices each, so 2×2×…×2 = 256 combinations, from 0 to 255), and memory is just one huge row of those bytes, each tagged by a number, its address.

Everything comes down to that: a letter fits in one byte (ASCII, a convention shared by every machine, fixes 'A' at 65), a word takes a few, an image takes millions, since each pixel is three numbers (red, green, blue). The millions of bytes in a photo are nothing magical: just an enormous pile of tiny 0/1 slots.

Why only two values? It does seem primitive. Because the physical world is noisy. A voltage in a wire drifts with heat, interference, the age of the components: telling ten levels apart (one per decimal digit) would demand an impossible precision. Two states, by contrast, are unmistakable, "off" or "on"; it takes enormous noise to confuse a 0 with a 1.

So the bit is the smallest piece of information that survives the noise, carried by the simplest and cheapest component we can make by the billions: a switch. And since two states map to true/false, all of logic and arithmetic build on top. Far from simplistic, it is the most robust trade-off there is. Other paths were actually tried: the 1945 ENIAC counted in decimal, the Soviet Setun of 1958 in ternary; binary won on reliability.

That leaves how a string of digits becomes a number. It all comes down to position. Start with base 10, the one we know. 234 is not "2, 3, 4" stuck together: each column carries a weight, units, tens, hundreds.

After the point, it keeps going downward: tenths (1/10), hundredths (1/100)… So 0.1 means "1 in the tenths column". The dot does not make the value, the column does.

Binary follows the very same rule, but with only two digits, and each column is a power of 2: 1, 2, 4, 8, 16… So 101 is 4 + 0 + 1 = 5.

A whole number is thus an exact sum of powers of 2: it always stores perfectly. After the point, the binary columns become fractions: 1/2, 1/4, 1/8, 1/16… A fractional number has to be written as a sum of those.

And 0.1 simply cannot. In binary, a fraction lands exactly only if its denominator (the bottom of the fraction) is a power of 2: 1/2, 1/4, 1/8… But 0.1 = 1/10, and 10 is not one. It hides a factor of 5 (10 = 2 × 5), and 5 never shows up when you keep doubling: 2, 4, 8, 16… So no finite sum of 1/2, 1/4, 1/8 ever equals exactly 0.1, and the expansion runs forever (0.0001100110011…). Just as 1/3 = 0.333… never lands exactly in base 10.

So how does it store the number at all? Not with a fixed point, but in binary scientific notation: just as we write 6.02 × 10²³ in base 10, the machine writes the number as a mantissa (the significant digits) times 2 to some exponent (which says where the point falls). That is what "floating point" means: the exponent floats the point, so one format holds both the huge and the tiny.

The exact bits of 0.1, for the curious (optional)

For 0.1, let's read the three pieces. The sign first: 0, because 0.1 is positive (1 = negative). The mantissa next: take 0.0001100110011… and slide the point to just after the first 1, which gives 1.100110011… × 2⁻⁴, whose digits repeat 1001 forever. A number normalized this way always starts with "1.", so that leading 1 is never stored: a free bit. The exponent last, -4. The 11 bits that store it can only encode positive numbers (0 to 2047), but -4 is negative. The fix: add a fixed offset of 1023, which always makes it positive. So the machine stores −4 + 1023 = 1019, written in binary as 01111111011 (and subtracts 1023 when reading to get -4 back).

But the mantissa is finite: 52 bits. We cut the endless pattern, and the last group is rounded up (…1001 → …1010). That is the crumb: stored 0.1 is a hair too big. 0.2 suffers the same, the crumbs pile up, and the total misses 0.3:

// what the machine actually stores (the "crumb"):
0.1        → 0.1000000000000000055…   // a bit too big
0.2        → 0.2000000000000000111…   // a bit too big
0.3        → 0.2999999999999999888…   // a bit too small

0.1 + 0.2  → 0.3000000000000000444…   // overshoots stored 0.3
0.1 + 0.2 === 0.3   // false → 0.30000000000000004
0.1 + 0.3 === 0.4   // true… but by luck!
0.1 + 0.7 === 0.8   // false, just like 0.1 + 0.2

That is the whole trap: 0.1 and 0.2 lean a touch too high, 0.3 a touch too low. Their sum overshoots the stored 0.3; the two are simply not the same number, so the equality is false.

And this miss is nothing special. Equality between two floats is a lottery: depending on whether the crumbs add up or cancel out, the final rounding lands right or wrong, with no way to guess. 0.1 + 0.3 really does give 0.4, but by luck; 0.1 + 0.7 misses 0.8.

The key fits in one line: an integer is exact, a float is not. Hence two reflexes: never compare two floats with ==, test instead whether they are close enough (their gap under a small tolerance); and store money in cents, as integers. The math becomes reliable again, and a whole class of rounding bugs disappears.

Write Great Code, vol. 1·Eloquent JavaScript

1.2 Memory is a pyramid

So far, memory was just a uniform row of bytes. In reality it has layers. Why? Because the CPU (the chip that runs your instructions one by one) only computes fast on data sitting right next to it. Closest of all are its registers, a handful of slots inside the chip: the only place it actually computes. Everything else lives further away, in tiers: the cache (a fast reserve glued to the chip, in L1, L2, L3), then RAM, then disk. Each tier you go down is roughly ten times bigger, but ten times slower. Except the last step: between RAM and disk it is no longer a step, it is a chasm (×100,000).

The orders of magnitude are dizzying: a register is near-instant, cache ≈ 1 ns, RAM ≈ 100 ns, disk ≈ 10 ms. To feel the gap, imagine a cache read took 1 second: RAM would then answer in ~1 min 40, and the hard disk… in ~4 months. A value you read often must therefore stay as high as possible.

Another reflex: the machine never fetches a single byte, it pulls a whole cache line (about 64 bytes) at once. So reading neighbouring cells is free; jumping all over is costly.

The classic case is the 2D array. Memory, remember, stays one long row of bytes. A two-dimensional array is therefore flattened into that row: its rows laid end to end, one after another. So a[i][j] is not a double lookup, but a single computed position, i × width + j.

From there, two traversals with opposite costs. Traversing a row (j moves) means stepping from one neighbouring cell to the next: each is already in the cache's 64 bytes, so free. Traversing a column (i moves) means jumping a whole array width each step: you leave the cache every time and it must reload, so slow.

(This assumes a truly contiguous array, as in C, Go or NumPy. An array of arrays (JS [[…]], Java int[][]) keeps each row elsewhere, allocated separately: there, the contiguity and the cache gain are gone.)

Same array, same work, only the order of the two loops changes:

// same logic, two loop orders over a 2D array
for (i...) for (j...) a[i][j]   // ✓ contiguous: the cache line is reused
for (j...) for (i...) a[i][j]   // ✗ jumps a row each time → up to 10× slower

On the dev side, it is the everyday trap: "load it all into memory". Pulling 100,000 rows from a database to display only ten blows the data far past the cache: every access then goes fetching far away, in RAM or on disk. Performance collapses, for the same underlying reason as the column traversal: moving data costs more than computing.

Write Great Code, vol. 1·vol. 2

1.3 Cost has a unit: Big O

Writing code that runs is good; knowing whether it holds when the database goes from a hundred rows to ten million is better. For that you need a unit of measure: Big O. It says how the number of steps grows with the input size, written n, while ignoring the constants (the machine, the language). Four classes show up everywhere:

• O(1): constant time, whatever the size (the fastest);
• O(log n): binary search halves the haystack every step;
• O(n): a single pass over the data;
• O(n²): every pair, which blows up fast (the worst here).

O(log n) feels abstract until the first example: finding a name in a sorted directory of one billion entries costs only about thirty steps, because halving a billion thirty times in a row lands on 1. That is why its curve flattens: doubling the data adds just one step.

O(1) is the most profitable idea of everyday work: a hash table (Python's dict, the JS object, PHP's associative array) finds a value by its key in constant time, even over a million entries. That is why you never write if (name in list_of_1000) (O(n): at worst, you scan the whole list) but if (dictionary[name]) (O(1): one direct access).

The gap is not theoretical. The clearest example: a computer from the 1970s, thousands of times slower than yours, but running a good algorithm (O(n)), beats a modern, blazing-fast machine running a bad one (O(n³)), as soon as the data grows. The lesson: no amount of computing power makes up for a bad algorithm.

Hence a habit that pays off: before writing a line, roughly estimate the number of operations. On ten million items, a single pass (O(n)) is ten million operations, a fraction of a second. Comparing them all pairwise (O(n²)) is ten million × ten million = a hundred trillion, hours of compute. Ten million times more: that thirty-second estimate tells you which one is viable before you even code.

The same logic drives the choice of data structure. An array stores its elements side by side: reaching the n-th is instant (you compute its address), but inserting in the middle forces you to shift every following element by one slot. A linked list links each element to the next by a pointer: inserting only re-wires two links, but to find the n-th you must follow the chain from the start. Neither is "better": you pick by what you do most, read or insert.

Grokking Algorithms·Programming Pearls

1.4 Think in the machine, write high-level

These days we write in clear languages (PHP, JavaScript, Python…), far from the machine's raw language. Between the two sits a translator: the compiler, which turns all the code into chip instructions before the run, or the interpreter, which translates during the run (PHP, Python; JavaScript mixes the two). The lessons that follow hold for both. Knowing this translator a little, and the machine it targets, still pays off, for two reasons.

First, it helps you smell a hidden cost behind a plain-looking line. The textbook case: recomputing the length of a text on every loop iteration, even though it never changes. The machine counts it in full, thousands of times for nothing; just compute it once, before the loop.

for (let i = 0; i < length(text); i++) { … }   // ✗ recounted on EVERY pass
const n = length(text);                          // ✓ counted once
for (let i = 0; i < n; i++) { … }

Second, it tells you what the compiler does for you, and what it never will. It optimizes small details on its own: it computes 3 × 4 once and for all, say, instead of redoing it every run. But it will never touch your big choices: it will not turn a slow search into a fast one. The algorithm stays your job; the machine only polishes what you hand it.

The low level also holds surprises. To go fast, the CPU bets ahead of time on the result of every if test (so-called branch prediction); when it guesses wrong too often, it loses time backtracking. An absurd but very real consequence: scanning a sorted array can be several times faster than the same scan over the same array shuffled, because the tests become predictable.

No one would ever guess that, and there are many hidden effects like it. The lesson: on performance, intuition is often wrong; the only reliable way to know whether code is fast is to measure it (actually time it), never to guess.

Write Great Code, vol. 2

2.1 Values and references: what the variable really holds

Does a variable hold the data itself, or only its address? Everything follows from that. For a number or a boolean, the variable is the data: assigning it to another copies it, and the two live separately.

But for an object, a list or a dictionary, the variable only holds a handle (a pointer, that is the memory address from chapter 1) to the data. Assigning it copies the handle, not the data: you end up with two names for one piece of data.

const a = [1, 2, 3];
const b = a;      // b shares the SAME backing array
b[0] = 9;         // a[0] is 9 too: one piece of data behind two names

In PHP, an object passed to a function is not copied: the function mutates the original. Confusing the two is an endless source of "I changed a copy and the original moved" bugs. Telling them apart is not a syntax trick: it is a mental model the language installs in you, and it is what lets you see the bug coming.

Learning Go·PHP 8 Objects

2.2 Types are sets of values

You know types by their names: int, string, boolean. But a type is more than a label: it is the set of values a variable can take.

• the type boolean holds only two values: true and false;
• the type 0 | 1 | 2 (a number that can only be 0, 1 or 2) holds three;
• the type string, infinitely many.

Seen this way, combining two types is operating on sets: their union (A | B) gathers all the values, their intersection (A & B) keeps only the shared ones, useful to require that one object honour two contracts at once.

This view also explains structural typing: a type is judged on what it has, not on its name. TypeScript does it on an object's shape (its properties); Go, on its interfaces (a type satisfies one as soon as it has the methods, without ever writing implements).

interface Point { x: number; y: number }
function length(p: Point) {…}   // length expects a Point: an x and a y
length({ x: 3, y: 4, z: 5 })      // ✓ ok: the {x, y} shape is there, the extra z is ignored

It is the opposite of nominal typing (Java, PHP), where the object must explicitly declare implements Point to be accepted. Here, the shape is enough.

That leaves Effective TypeScript's most profitable idea, which fits in two opposite words:

let a: any     = JSON.parse(s);  a.foo.bar  // ✗ "trust me": 0 checks, crashes at runtime
let b: unknown = JSON.parse(s);  b.foo      // ✓ compile error: prove what it is first

any switches the compiler off and silently contaminates everything it touches; unknown says "I don't know yet, I'll check before acting". Choosing unknown keeps the net.

Effective TypeScript·Learning Go

2.3 Functions are values

In modern languages a function is a value like any other: you store it in a variable, pass it as an argument, return it. That single idea unlocks three tools. They are really three ways of thinking the language opens up, each magical until you see the mechanism:

• the closure: a function that remembers the variables of the place it was born (a counter that keeps its private total from one call to the next);
• the decorator: a function that wraps another to add behavior without touching its code (timing, caching, checking permissions, in one line);
• the generator (yield): a function that produces its values one at a time, on demand, instead of computing them all up front (walking a huge file without loading it whole).

The most surprising of the three is the closure. An example in Python:

def counter():
    n = 0
    def inc():
        nonlocal n; n += 1; return n   # inc REMEMBERS n (closure)
    return inc

This mechanism is everywhere: JavaScript and Go capture the variable on their own; PHP asks you to declare it explicitly, with use (&$n). Above all, it beats a static (a variable that survives from one call of the function to the next):

• a static keeps one state, shared by the whole function;
• every call to counter() builds a brand-new private n: as many independent counters as you want (the inc() functions born from the same call share theirs).

At heart, a closure is a machine for making private state.

The decorator follows directly. The classic one: timing a function without touching its code:

def timer(f):               # takes a function, returns another
    def wrapper(*a):
        t = time(); r = f(*a); print(time() - t)   # runs f and measures its time
        return r
    return wrapper

@timer                      # @ : wraps slow(), which is now timed
def slow(): ...

And the generator, the most counterintuitive, dodges the "load it all into memory" trap from chapter 1 by delivering its values one drip at a time, on demand:

def lines(file):
    for line in file:
        yield line        # hands back one line, pauses, resumes at the next
# → read a 50 GB file without ever loading it whole into memory

Fluent Python pushes the idea even further: not just functions, any object "speaks" the native language as soon as it implements the right special methods. Give your class a __len__, and len(my_object) works; an __iter__, and for x in my_object works, without inheriting from anything. That is the data model: you don't configure Python, you plug into it.

Fluent Python·Eloquent JavaScript

2.4 Recursion: solving a problem with a smaller version of itself

A function that calls itself? At first it sounds like an infinite loop, but it isn't. It all hinges on two parts:

• the base case: tiny, solved directly, without calling itself again;
• the general case: the problem reduced to a smaller version of itself.

Since each call shrinks the problem, you always land on the base case. Without it, it's two mirrors facing each other: it never stops.

The trick to writing it without tying your brain in knots: handle the base case, then trust the smaller call, assuming it already works. You don't unroll the whole cascade in your head.

def fact(n):
    if n <= 1: return 1        # base case
    return n * fact(n - 1)     # reduce to a smaller problem
# fact(3) = 3 × fact(2) = 3 × 2 × fact(1) = 6

Under the hood, each call waits for the next one's result: they pile up (the call stack), then unwind, passing results back up. Hence a very real limit: recursion that is too deep overflows the stack (the famous stack overflow).

It is the natural tool for anything tree-shaped (shaped like a tree: a branch that splits into smaller branches):

• walking a folder and its subfolders;
• an HTML tree, the DOM (the page seen as nested tags);
• a nested JSON.

The code then matches the shape of the data and gets far shorter than with loops.

Grokking Algorithms·Eloquent JavaScript

2.5 Permissiveness has a price

Some languages accept almost anything, and that is a trap that snaps shut in silence. JavaScript converts types into one another on its own (text, number, boolean): that is coercion. Depending on context, the same + adds or glues end to end.

0 == false    // true  (== converts false to 0, then compares)
0 === false   // false (=== compares without converting: 0 is not false)
"5" - 1       // 4     (- makes no sense on text → "5" becomes 5)
"5" + 1       // "51"  (+ sees a string → 1 becomes "1", then glued)

The golden rule comes down to one character: always ===, never ==. And it is precisely this permissiveness that TypeScript, the safety net of 2.2, came to rein in. Knowing a language's permissiveness is knowing its bugs before you write them.

Eloquent JavaScript

2.6 Naming a concept changes what you can think

A language's real power is to name abstractions. Once you can say "a list", "an interface", "a promise", you reason about it without re-deriving the plumbing underneath. Take two of those names, in two languages.

First name: the interface. In Go, a type implements one without ever declaring so: it just needs the right methods. This is the structural typing of 2.2, applied to interfaces: a type is judged on what it can do, never on its name.

The consumer says "I need something that can do X" without knowing the concrete type behind it; the provider has nothing to declare. That one name is enough to decouple the user from the supplier: it is the seed of all the architecture in chapter 4.

Second name: the promise, the one that stings for every JavaScript beginner. Some operations take time, like fetching data from a server. JavaScript does not freeze while it waits: it keeps going, and calls you back once the result arrives (this is async).

Before, you handed it a function for that, a callback: "when you are done, run this". But as soon as one request needs the result of the previous one, you nest a callback inside a callback inside a callback: the code drifts to the right and becomes unreadable. That is the infamous "callback hell".

// ✗ without the word: a callback inside a callback inside a callback
get(a, r1 => get(r1, r2 => get(r2, r3 => show(r3))))

The promise, instead, names "a value that will arrive later". The keyword await means "wait here until the value arrives, then hand it to me as a normal variable". The same chain then reads top to bottom, like ordinary code:

const r1 = await get(a);    // wait for the 1st result
const r2 = await get(r1);   // then the 2nd, which depends on the 1st
show(await get(r2));         // then the 3rd

Same work for the machine, same network wait: only the name changed what you can write and follow. Interface or promise, it is the same lesson: a well-chosen name makes you forget the plumbing and think one level up. That is the whole chapter in one idea.

Learning Go·Eloquent JavaScript

3.1 The name reveals the intent

A good name makes the comment unnecessary. It must answer three questions at once:

• why it exists;
• what it does;
• how you use it.

Compare the raw condition with the same intent, named:

// ✗ you decode the business rule on every read
if (age >= 18 && balance > 0 && !suspended) { ... }

// ✓ the name IS the explanation; the rule lives in one place
if (canPlaceOrder(customer)) { ... }

This is chapter 2's power to name, brought down to the scale of a single variable.

Clean Code

3.2 The deep function, not just the short one

Here two masters clash, and the quarrel is instructive:

• Clean Code: functions should be small, then smaller than that;
• A Philosophy of Software Design: past a point, cutting further helps no one.

The real question is not "how many lines?" but "is it simpler for the caller?". Take a price to compute: net, VAT, discount, shipping.

// ✗ over-split: 4 micro-functions the caller must chain by hand
const net        = readPrice(c);
const taxed      = applyVat(net);
const discounted = applyDiscount(taxed, c);
const total      = addShipping(discounted, c);

// ✓ a "deep" function: one call, the 4 steps hidden inside
const total = finalPrice(c);

The decomposition itself is not the problem: finalPrice can perfectly well call those four steps internally. What changes is that they become private; the caller sees a single name instead of orchestrating the chain itself.

The deep function thus offers a tiny surface (one name, one argument) for a lot of hidden work. Split, yes; expose, no. You merge in one case only: two steps so welded that you can't understand one without the other. Splitting them would create conjoined methods, the over-splitting A Philosophy of Software Design warns against.

Clean Code·A Philosophy of Software Design

3.3 The comment says why, not what

On comments, Clean Code is scathing: Robert Martin goes as far as writing that comments are always failures, proof you couldn't express yourself in the code. A comment that merely paraphrases the code proves him right: it ages and ends up lying, because the code changes and it does not.

i++;  // ✗ increment i           (the code already says this: useless)
i++;  // ✓ skip the header byte; malformed packets omit it

But banning them all would be the opposite excess. A Philosophy of Software Design, by John Ousterhout, restores the balance: the good comment says what the code cannot. Three kinds are worth writing:

• the why: the non-obvious decision, the trade-off behind the code. // in cents: zero floating-point rounding
• the warning: the trap, the order you must not break. // do NOT reorder: validate before saving
• the contract: what a function promises its caller (what it expects, what it returns, its side effects), so you never have to read its body.

It is even a detector: when a comment grows long and painful to write, it is "the canary in the coal mine", a sign your abstraction (how you carved up the problem) is bad. Ousterhout even writes them before the code, as a design tool.

Clean Code·A Philosophy of Software Design

3.4 Define the error out of existence

The most underrated idea: the best error handling is the error that does not exist. Rather than catching an exception everywhere, you redefine the semantics (the very meaning of the operation) so the error case becomes a normal one.

// ✗ Java: throws an exception, to be guarded against everywhere
"hi".substring(0, 10);   // 💥 IndexOutOfBounds

# ✓ Python: an out-of-range slice clamps to what exists, no error
"hi"[0:10]               # → "hi"

And it works in your own code, not just a language's standard library (the functions shipped with it). Rather than forcing every caller into a repeated if (user == null) throw, return a "guest" object that responds like a real user:

// ✗ every caller must remember to test for null
if (user == null) throw ...; user.name();

// ✓ "Null Object": no user = a Guest that knows how to answer
user.name();   // → "Guest", empty rights: the error case is gone

It is the same instinct as "pull complexity downwards" (absorb it inside the module rather than push it onto the callers): let one team suffer once inside, rather than a thousand callers outside.

A Philosophy of Software Design

3.5 Don't repeat yourself, and make change easy

DRY (Don't Repeat Yourself) is one of the most misread principles in the craft. It is not "don't copy-paste code", it is "every piece of knowledge has a single, authoritative home in the system". The word that counts is knowledge, not code, and two counterintuitive consequences follow.

Identical code is not always duplication. If two fragments look alike by chance and will evolve for unrelated reasons, merging them couples them wrongly. An item's price is validated with price > 0, its stock quantity with quantity > 0: tempting to merge both into a single isPositive(). But tomorrow stock must allow 0 (out of stock), the price must not: they were two rules, identical by coincidence.

And you repeat yourself without copying a single line. The same knowledge leaks elsewhere: a validation rule rewritten on the client and the server, a table's structure the code re-describes by hand, or a comment restating what the code already does, the very comment-paraphrase trap from above. No copy-paste, yet two truths to keep in sync.

The cure is one word: each piece of knowledge gets a single home; the rest of the code refers to it instead of re-knowing the same thing on its own.

And behind DRY stands a broader value, ETC (Easier To Change). It is not one more rule but a compass: at every choice, one question, "will this make the system easier, or harder, to change?". Decoupling, good names, DRY itself are only special cases of it, and it carries the whole next chapter: architecture is ETC at the scale of the system.

// ✗ every new channel reopens the function
if (channel == "email") ... else if (channel == "sms") ...

// ✓ a table {channel → notifier}: a new channel = one extra row, the logic stays put
notifiers[channel].send(message)

The Pragmatic Programmer

3.6 Refactoring is changing form without changing behavior

Refactoring is not "rewriting": it is reshaping the internal structure without touching observable behavior. A test that passed before passes after; otherwise it is no longer a refactoring, it is a modification.

You move in small safe steps, guided by "smells" (the signs that betray badly structured code). One of the most common, the Data Clump: a group of parameters that always travel together is asking for a class.

ship(name, street, city, zip)   // ✗ 4 params glued together everywhere
ship(address)                   // ✓ they were one concept: an Address class

And the key, counterintuitive move is a line from Kent Beck: make the change easy, then make the easy change (reshaping first can be the hard part). Need to wire up PayPal? First you refactor so a payment method becomes interchangeable, behavior untouched; then you add PayPal almost for free.

But those small steps are only safe with a net. Fowler hammers it: without a suite of tests confirming at each step that observable behavior hasn't moved, refactoring becomes a blind bet (more on that in chapter 5).

And the daily reflex fits in one image, Clean Code's boy-scout rule: always leave the file a little cleaner than you found it. Not scrub everything, just your own mess: cleanliness becomes a tide, not a spring-clean you postpone forever.

Refactoring

4.1 Compose rather than inherit

The first reflex for reuse is inheritance: a child class inherits from a parent. The trap: it inherits everything, even what it does not want, and a change in the parent breaks the child at a distance. Head First's classic example: every duck inherits fly()… then the rubber duck shows up and inherits it too, though it cannot fly. Composition fixes this: fly() becomes a separate object the duck has instead of inheriting it, one you plug in and swap (real flight, or none) without touching the duck, even while the program is running.

// ✗ inheritance: flying is frozen in the hierarchy
class RubberDuck extends Duck { }  // inherits fly()… but cannot fly!

// ✓ composition: behavior is an injected object, swappable
duck.flyBehavior = new CannotFly()

"Favor composition over inheritance" is the very first principle of patterns.

Head First Design Patterns·Design Patterns (GoF)

4.2 A pattern answers a need, not a goal

A design pattern is not decoration you slap on to look serious: it is a proven answer to a recurring problem.

• Strategy: swap an algorithm at runtime;
• Observer: notify a list of subscribers when a state changes;
• Decorator: stack responsibilities without subclassing.

None is wizardry; the Observer, for instance, is just a list of functions called back on every change:

subject.subscribers = [refreshView, sendMail]
subject.change(state) { subscribers.forEach(fn => fn(state)) }  // everyone is notified

The GoF (the "Gang of Four", the four authors of the founding Design Patterns book) sorts its 23 patterns into three families, and that frame beats the list:

• Creational (how to instantiate): Factory, Singleton, Builder;
• Structural (how to assemble): Decorator, Adapter, Composite;
• Behavioral (how to communicate): Strategy, Observer, Command.

You don't memorize 23 recipes: you ask one question, "is my problem to create, to assemble, or to communicate?", and the corridor narrows to a few candidates.

Above them all, the book's founding principle: program to an interface, not an implementation. Your code works with what an object can do, never with what it is.

// ✗ to an implementation: the code is welded to a specific class
export(doc) { new PDF().write(doc) }          // can only do PDF

// ✓ to an interface: "something that can write()"
export(doc, output) { output.write(doc) }     // PDF, CSV, HTML… : what it DOES, not what it IS

And the final rule: you do not apply a pattern, you recognize it when the need calls for it. The number-one danger is over-application: forcing a problem into a pattern where a simple solution would do, like a Factory that wraps a single new.

Design Patterns (GoF)·Head First

4.3 Depend on abstractions, invert the dependencies

Here, everything turns on the direction of the dependencies. Clean Architecture's dependency rule: stable, important code (the business rules) must never depend on volatile code (the database, the framework, the UI). You invert the usual direction: the business declares an interface, the infrastructure conforms to it.

// the business declares WHAT it needs (an interface)
interface CustomerRepo { find(id): Customer }
// infra (SQL, API…) implements it; the business knows nothing of it
// → you swap databases without touching a line of business code

It is the "I need something that can do X" of chapter 2, scaled up to a whole system: boundaries protect what matters from the rest. Martin goes further with a striking line: the database and the framework are details, just like the brand of the electrical wiring in a house. You don't design the house around the wires; your business code should not even know MySQL exists.

SOLID formalizes this, five rules, one per letter:

• S (Single Responsibility) — one class, one reason to change;
• O (Open/Closed) — open to extension, closed to modification;
• L (Liskov Substitution) — a subtype must replace its parent without surprises;
• I (Interface Segregation) — many small interfaces beat one huge one;
• D (Dependency Inversion) — depend on the abstraction, never the concrete (what we just saw).

Clean Architecture

4.4 No "best practice", only the least-bad trade-off

The higher you climb, the fewer universal answers there are. Hard Parts puts it bluntly: "for architects, every problem is a snowflake." The skill is not picking the right pattern, it is weighing trade-offs. Two tools for that.

The first, the architecture quantum: the smallest piece you can deploy, test and fail alone. Two services sharing the same SQL table are like two flats behind a single circuit breaker: one cuts the power, the other is in the dark. They are a single quantum.

The test, for any diagram: "if this component changes or crashes, how many others fall with it?" That number is the size of your quantum. Twenty "microservices" on a shared database? A single quantum, again.

The second, "reuse is coupling": sharing a business class across services propagates every change everywhere at once. Hence a counterintuitive reflex: you sometimes duplicate on purpose. Share only what is genuinely one piece of knowledge that must stay consistent (the DRY of chapter 3); for two bits that merely look alike but will evolve apart, a little copying beats a bad coupling.

Neither is settled on principle. A small quantum buys independence, sharing buys consistency, and each is paid for: one in duplication and network, the other in coupling. You choose case by case, by what matters most here: no rule, only the least-bad trade-off.

Software Architecture: The Hard Parts

4.5 Conceptual integrity: one mind

The finest architecture dies if forty teams stack their ideas without coordination: the API where each names "identifier" differently and formats dates its own way. Each piece works alone; the whole is unreadable.

// ✗ three teams, three names for the same id, three dates
GET /users   → { id,     "2026-06-09" }
GET /orders  → { userId, "06/09/2026" }
GET /cart    → { uid,    1749427200 }

// ✓ one vocabulary, one format: the caller can guess everything
GET /users · /orders · /cart → { id, "2026-06-09" }

The Mythical Man-Month, by Fred Brooks, is firm: "conceptual integrity is the most important consideration in system design." It must come from a single mind, or a very small group, or it becomes the tower of Babel.

One mind doesn't mean one person coding it all: that handful decides the form, the others fill it in. And Brooks insists: "form is liberating". Once the structure is fixed, everyone knows where their piece fits, and codes faster, not slower.

The Mythical Man-Month

5.1 Test first

Writing the test before the code inverts the usual order, and that changes everything: you define the expected result before knowing how to get it. The cycle repeats endlessly: Red (a failing test), Green (the dumbest code that passes, even hard-coded), Refactor (clean without breaking).

// 1. RED: the test BEFORE the code
test('5 + 3 = 8', () => expect(sum(5, 3)).toBe(8))   // ✗ fails

// 2. GREEN: the dumbest code that passes (yes, "8" hard-coded)
function sum(a, b) { return 8 }                         // ✓ green, no shame

// 3. REFACTOR: a 2nd test breaks the "8", you generalize
function sum(a, b) { return a + b }                     // ✓ clean, still green

You never refactor on red. The goal, in four words: clean code that works.

But the deepest effect of TDD (Test-Driven Development) is not catching bugs, it is emergent design: writing the test first, you design the API from the point of view of the caller, not the implementer. The code becomes modular and decoupled because it has to be testable.

You don't draw the architecture up front, you let it emerge, test after test. That is what makes chapters 3 and 4 easier to hold.

Test-Driven Development: By Example

5.2 Versioning is a content-addressable system

Versioning is the flow's safety net: you change anything, you experiment, you work with others without colliding, and you can always go back. Proof by fear: you just wiped out three days of work with a mis-aimed git reset --hard. Panic. Except in Git, almost nothing truly disappears, and understanding why changes everything.

Git is not a history folder: it is a database of objects, each addressed by its fingerprint: a short digest computed from the content (the "hash", produced by the SHA-1 function). The same content always yields the same hash, so nothing is lost or silently forged. Everything chains by pointers:

git cat-file -p HEAD   # shows this commit: its tree, its parent, the author

And before entering that graph, a file passes through three zones, which finally explains why git add exists:

git add saves nothing: it photographs the exact version of a file for the next commit. The commit seals that photo into the graph. That is why you can commit only part of your changes.

And your three wiped days? The commit before the reset is still there, an immutable object in the database; git reflog lists the recent hashes, you point a branch back at it, and it all returns. Understanding the graph is how you ship without panic.

Pro Git

5.3 Flow beats effort

The Phoenix Project teaches, through a novel, a merciless factory law: a task's wait time explodes as a resource (a server, a team, a person everything depends on) approaches 100% utilization.

wait time ≈ % busy ÷ % free   // the queueing law

Why the wall? At 99% utilization, no slack is left to absorb the unexpected: one task that drags, one burst of arrivals, and the queue swells with no way to drain. At 50%, the spare time soaks up those bumps as they come.

"Everyone is flat out" and "nothing moves" are therefore the same sentence. The remedy is counterintuitive: limit work in progress, stop starting things to actually finish some. Slack is not waste: it is what lets work flow.

The Phoenix Project

5.4 Shipping often is less scary than shipping rarely

The big release prepared over months is a cannon shot: once fired, nothing can be corrected. A burst of small deliveries, by contrast, adjusts continuously.

Accelerate measures it: teams that deploy often and with loose coupling (shipping without asking another team's permission, the quantum of chapter 4) are both faster and more stable, it is not a trade-off. You get there with tools like feature flags (ship code switched off, then flip it on) or blue-green deployment (switch between two versions in one reversible flip).

And above all, Accelerate gives four numbers to measure yourself objectively, the DORA metrics (DevOps Research and Assessment, the research team behind the book):

• lead time: time from a commit to production;
• deployment frequency: how often you ship;
• MTTR (Mean Time To Recovery): time to restore service after an outage;
• change fail rate: what % of deployments break something.

Elite teams ship several times a day and recover in under an hour; the weakest ship every six months (State of DevOps surveys, thousands of teams polled between 2014 and 2017). And the same practices reduce burnout: "deployment pain" predicts team exhaustion.

Accelerate·The Phoenix Project

5.5 Reads scale by copying, writes by splitting

The service survives deployment; the load remains. A million readers on a single database, and every query waits in the same line. The read-side answer: copy. Replication duplicates the database across machines that all serve reads; the cache keeps already-computed answers close by (Redis, a CDN: the pyramid of chapter 1, at datacenter scale); the index avoids scanning the whole table, the way a book's index saves you from leafing through 500 pages.

Copying does not help writes: every copy would have to absorb every write. Writes you split. Sharding spreads the data in slices (customers A-M here, N-Z there), and each machine only takes its share. And this is where the trouble starts: data scattered across several machines is exactly the situation where the guarantees die.

Designing Data-Intensive Applications

5.6 At scale, guarantees have a price

On a single database, you live protected without knowing it. A transaction there is all-or-nothing: the transfer debits AND credits, or does nothing at all. That is the ACID contract (a transaction that is atomic, consistent, isolated, durable), and the engine gives it to you for free: if step 2 fails, it undoes step 1 on its own (the rollback).

Then the service grows, the data spreads across several machines, and that contract dies in silence: nobody can undo "everything" anymore, each machine only sees its own piece.

New anomalies appear, invisible on a single database. The nastiest one, write skew: two transactions, each perfectly valid, that break a rule together. The book's example: a hospital requires at least one doctor on call. Alice and Bob, the last two on call, sign off at the same moment. Alice's transaction checks "is Bob still there? yes" and commits; Bob's checks "is Alice still there? yes" and commits. Each saw a world where the rule held; together they leave zero doctors. No error was ever raised anywhere.

With no global rollback, you write the undo by hand: that is the saga. Placing an order = reserve the stock ①, charge the card ②, create the shipment ③; if ③ fails, your own code triggers the refund of ② then the release of ①. What the engine used to do for free becomes your job, step by step.

The distributed-systems moral fits in one line: the network lies, the clock lies; "suspicion and paranoia pay off".

Designing Data-Intensive Applications·The Hard Parts

6.1 Don't make me think

A user does not read a page, they scan it, and every half-second of hesitation is a friction that drives them away. Hence the law usability consultant Steve Krug laid down in 2000, which gives the book its title: don't make me think. Conventions beat creativity (the magnifier top-right, the cart next to it) because the user finds them without thinking, on every site they already know.

And every visitor arrives with a reservoir of goodwill that each bad decision drains. You spent twenty minutes filling your cart; total $45; you click "checkout"; shipping: $12. You close the tab. That is the reservoir run dry, by one number hidden too late. Filling it is the opposite: be transparent, forgive a format slip, never block the way with an animation.

Don't Make Me Think

6.2 An API is designed for its caller

An API (application programming interface) is the contract by which one program calls another, most often over the web. Its universal vocabulary is the HTTP verbs: GET to read, POST to create, PUT/PATCH to update, DELETE to remove. They state intent without reading the docs: GET /users/42 guesses itself. And the golden rule of Arnaud Lauret, the book's author, is consumer-first: you don't start from your database, you start from what the caller wants to do, draw the ideal response for them, then build backwards, all the way to the database.

Beyond that: predictable names give superpowers (you guess the rest); an error must be generous (say what is wrong, where, and all at once); and the safest data is the data that does not exist, expose only the strict minimum.

// ✗ guessed by nobody           // ✓ guessed by everyone, and standard
{ "ACTBLNDFPRTF": true }        { "overdraftFacility": { "active": true } }

The Design of Web APIs

6.3 Accessible by construction

A blind person does not see your button; their screen reader announces it, as three pieces of information: a name (the text read out), a role (what kind of thing it is), a state (checked, open, disabled).

<button aria-pressed="true">Favorite</button>   // announced: "Favorite, button, pressed"

A clickable <div> has no role and no state: to a screen reader, it does not exist. Hence the first rule of ARIA (Accessible Rich Internet Applications, the aria-* attributes in the code above): use the right HTML element, which provides all three for free. All of this is framed by a global standard, the WCAG (Web Content Accessibility Guidelines), four principles (Perceivable, Operable, Understandable, Robust) and three levels (A, AA, AAA). Two concrete moves cover the essentials: enough contrast (a 4.5:1 ratio on text), and keyboard navigation.

/* ✗ the most common mistake: removing the focus outline */
button:focus { outline: none; }
/* ✓ a visible focus: the keyboard user sees where they are */
button:focus { outline: 2px solid #005fcc; }

The ultimate free test: drop the mouse, walk your page with the Tab key. If you lose track, a keyboard user does too.

Web Accessibility Cookbook

6.4 The organization shows up in the code

So far we have looked at the software from the outside: the user, then the developer who calls the API. Let us switch figures: who builds this software? The organization itself is an interface. Conway's law: a system copies the communication structure of the organization that builds it. Four teams that talk poorly will produce four modules that fit poorly, like it or not.

Team Topologies turns the law into a lever: if you want a certain architecture, organize the teams for it first. The hidden constraint is cognitive load: a team can only hold a bounded amount of domain. So you split the system along its fracture planes, its natural seams, most often the business domain. And the book gives the playbook, four team types:

• stream-aligned: one team = one product, shipped end to end (the default case);
• platform: provides internal tooling so the others ship without waiting;
• enabling: helps a team level up, then steps away;
• complicated-subsystem: maintains a piece too specialized to share (a calculation engine, say).

Team Topologies

6.5 Adding people to a late project makes it later

Intuition says: project is late, add developers. It is false, and it has a name, Brooks's law. The work divides badly, each newcomer must be trained (by the veterans, whom you therefore slow down), and above all they multiply the communication channels.

communication channels = n × (n − 1) ÷ 2
 5 people → 10 channels        // manageable
15 people → 105 channels       // half the time goes to coordination

"The man-month is a mythical unit": men and months are not interchangeable. Nine women do not make a baby in one month.

The Mythical Man-Month

6.6 Think like the attacker to defend

The chapter's last figure, the least friendly: the attacker. You only defend well what you know how to attack. The classic flaws are all a variant of the same sin: data coming from the user, treated as code, or taken at its word. XSS (injected HTML that runs), SQL injection (an input that closes the query and chains its own: '; DROP TABLE users --), or mass assignment, a field slipped into the request that promotes its sender:

POST /api/profile  { "name": "Alice", "isMember": true }
user.update(req.body)   // ✗ isMember goes through → Alice self-promotes

The defense: never trust the input, and defense in depth, where each layer protects itself (validation on input, and prepared queries at the database, and security headers on the server: if one gives way, the others hold). And the right vocabulary: "mitigations", not "fixes", because no defense is ever final.

Web Application Security

7.1 AI generates the probable, not the true

A language model does not know what is true: it produces, word after word, the most probable. Hallucination is therefore not a bug to be fixed one day, it is the very mechanism that makes it work: "anything with a non-zero probability, however wrong, can be generated". Ask it for the author of an obscure book: with the very same confidence, it will hand you a plausible, false name. The practical consequence governs everything else: you never trust blindly, you verify, and you design the system around that uncertainty rather than against it.

AI Engineering

7.2 Everything turns on context

A model fails first when it lacks information. Giving it the right context at the right moment has become THE skill. The RAG pattern (Retrieval-Augmented Generation: generate while leaning on retrieved documents): fetch the relevant documents from an external base and paste them into the prompt before the answer, so the model leans on supplied facts, not its fuzzy memory.

docs = base.search(embed(question), top_k=3)     # embed = turns the question into
                                                 #   a vector, to search by meaning
                                                 #   top_k=3: keep the 3 closest
prompt = f"Answer using THIS: {docs}\n\n{question}"      # 2. paste them in
answer = llm(prompt)                             # 3. answer from facts

Context is also shaped in the prompt itself, and the difference is brutal:

# ✗ vague → fanciful answer, unpredictable format
"summarize this"

# ✓ role + context + enforced format → usable answer
"You are a lawyer. Summarize this contract in 3 bullets, cite the clause for each."

And the real bottleneck is not the model, it is evaluation. The pipeline answered: is the answer good? You cannot just "look"; you need a grid (are the sourced facts there? was anything false added? is the tone right?). Without that grid you iterate blind, exactly like code without tests (chapter 5). This is also where the fine-tuning vs RAG choice is made: retrain a model on your data, or just hand it the right documents at answer time; the second is enough in the vast majority of cases.

AI Engineering

7.3 The surgical team, finally feasible

Brooks dreamed in 1975 of a surgical team: one brain holding the scalpel (designing, deciding), surrounded by roles that amplify its effectiveness, the copilot who knows all the code, the language lawyer who memorizes the API, the toolsmith who forges the tools. The dream hit a wall: it required "hands" both excellent and plentiful, impossible to find. AI is exactly those hands. You hold the scalpel; the assistant knows all the code, generates the scripts, remembers the API by heart. The model imagined fifty years ago finally becomes practical, the day the hands are a machine. AI does not repeal Brooks's law (chapter 6): it changes its parameters, because these "hands" cost neither training nor a communication channel.

The Mythical Man-Month·AI Engineering

7.4 Human judgment is the last link

If AI writes the code, what is left for the human? Everything above. To judge whether the generated code is right, you must:

• understand what it costs (chapter 1);
• know whether the language expresses it well (chapter 2);
• judge whether it is readable by the next human (chapter 3);
• see whether it fits the architecture (chapter 4);
• be able to prove it and ship it (chapter 5);
• check that it serves the human, and resists the attacker (chapter 6).

AI produces the probable; you decide what is right. The faster it writes, the rarer your judgment becomes. This whole book does not teach you to code instead of the AI: it teaches you to know when it is wrong. It will never know, on its own, that an amount should live in cents rather than a float (chapter 1): you have to know it.

AI Engineering