#software-engineering

Run a better book club

Notes from a moderately-successful book club I ran for Designing Data-Intensive Applications.

Cohesion vs Coupling

One-way doors vs two-way doors

Stable Dependencies Principle

What developers miss about the Single Responsibility Principle

The real meaning of the "S" in SOLID: a module should have one, and only one, reason to change.

How to estimate work like a senior software engineer

A structured process for making software estimates that are more accurate than shots in the dark.

What exactly is tech debt?

Defining and quantifying technical debt: what it is, where it comes from, and how to measure its impact on your team.

Conway's Law

System boundaries tend to follow communication boundaries. Plan for that or pay in meetings and glue code.

YAGNI

Defer capabilities until need is proven; speculative code costs build time, calendar time, and carry weight in the codebase.

Gall's Law

Working complex systems started as working simple systems

Hick's Law

Why choice reaction time scales with the log of alternatives, and what that buys you in menus, settings, and incident tooling.

Unix philosophy

McIlroy's pipes-and-tools rules still explain good CLIs and composable services, even when the universal interface is JSON.

Occam’s razor when you pick models

Why the familiar razor about unnecessary entities is sharper as a habit of work than as a slogan, across code, debugging, and ML.

Amdahl's law

Why parallel hardware stops helping once a fixed slice of work stays serial.

Dunning-Kruger, self-assessment, and software work

What Kruger and Dunning measured in their studies, why the pop account misleads teams, and how to run reviews and hiring without treating confidence as a personality probe.

Parkinson's law and software schedules

Why slack in a deadline often turns into scope, polish, and meetings instead of safety margin.

Cunningham's Law

Why wrong claims draw corrections faster than plain questions, and why the famous line is a shaky match for Ward Cunningham's own story.

KISS in software design and review

Why Keep It Simple is a habit for design and review, and how to tell simplicity apart from cleverness.

Broken windows in software

Visible neglect in a codebase invites more neglect; small repairs compound.

Fitts's law

Why pointing time depends on distance and target size, and what that means for dense UIs, touch, and tools.

Law of leaky abstractions

Why every useful abstraction eventually forces you to learn what it hides, and what that means for frameworks and APIs.

Moore's Law

Why the transistor cadence shaped software economics, and what changes when that cadence stretches.

90-9-1 is the shape of the room

Heavy lurker and superuser skew is normal in participatory systems, which matters when you read feedback or run an internal forum.

CAP theorem and what partitions force

Eric Brewer's CAP conjecture became a precise impossibility result for linearizable read-write services under arbitrary message loss.

Pareto principle

A small share of causes usually drives most of the effect; use the skew as a testable guess, not a debate club.

Brooks' law

Fred Brooks on why staffing up a late project often pushes the finish line out, not in.

Hofstadter's Law

Why software work slips after you add slack, and how the joke about recursion maps onto real plans.

Dunbar's number and engineering orgs

What Robin Dunbar's ~150 limit claims, and how it shows up in org design, on-call, and communication load.

The ninety-ninety rule

Why the last slice of a build eats most of the calendar, and what to do about it.

Murphy's law for engineers

Treat Murphy's law as risk hygiene, not fate. Defensive design, testing, and SRE habits turn the slogan into something you can ship.

Postel's Law

Why 'be conservative in what you send, liberal in what you accept' still shapes APIs and parsers, and where it breaks.

Goodhart's law and engineering metrics

Why velocity, coverage targets, and badly written OKRs invite gaming once they become the scoreboard.

DRY principle

Hunt and Thomas on why duplicated knowledge is a maintenance tax, and when merging similar code makes change harder.