Notes (67)
The real meaning of the "S" in SOLID: a module should have one, and only one, reason to change.
A structured process for making software estimates that are more accurate than shots in the dark.
Defining and quantifying technical debt: what it is, where it comes from, and how to measure its impact on your team.
System boundaries tend to follow communication boundaries. Plan for that or pay in meetings and glue code.
Defer capabilities until need is proven; speculative code costs build time, calendar time, and carry weight in the codebase.
Why choice reaction time scales with the log of alternatives, and what that buys you in menus, settings, and incident tooling.
McIlroy's pipes-and-tools rules still explain good CLIs and composable services, even when the universal interface is JSON.
Why the familiar razor about unnecessary entities is sharper as a habit of work than as a slogan, across code, debugging, and ML.
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.
Defaulting to non-malicious explanations in incidents, postmortems, and everyday teamwork.
Why slack in a deadline often turns into scope, polish, and meetings instead of safety margin.
Why wrong claims draw corrections faster than plain questions, and why the famous line is a shaky match for Ward Cunningham's own story.
Why Keep It Simple is a habit for design and review, and how to tell simplicity apart from cleverness.
Visible neglect in a codebase invites more neglect; small repairs compound.
Why pointing time depends on distance and target size, and what that means for dense UIs, touch, and tools.
Why every useful abstraction eventually forces you to learn what it hides, and what that means for frameworks and APIs.
Why the transistor cadence shaped software economics, and what changes when that cadence stretches.
Heavy lurker and superuser skew is normal in participatory systems, which matters when you read feedback or run an internal forum.
Eric Brewer's CAP conjecture became a precise impossibility result for linearizable read-write services under arbitrary message loss.
20% of the product takes 80% of the time. And 80% of the impact is driven by 20% of the product.
Why software work slips after you add slack, and how the joke about recursion maps onto real plans.