A reading map for humane code, clear models, useful feedback and systems we can understand. 20 selected profiles, with reasons to borrow an idea and reasons not to borrow it blindly.
Human-scale code and earned abstractions
Sandi Metz
Selected design influence
Why the ideas fit: Her account of a shared method accumulating parameters and branches gives our small-method and no-speculative-abstraction rules a concrete test. When cases diverge, inlining the wrong abstraction can expose the differences needed for a better design.
Where the fit has limits: This is not a ban on abstraction or removing duplication. The remedy concerns an abstraction shown to be wrong.
Put it to work: Before adding another mode flag to a shared helper, examine whether its callers still express the same idea.
Read: The Wrong Abstraction
Bret Victor
Outside perspective; partial alignment
Why the ideas fit: His interactive examples expose vocabulary, state and execution instead of requiring learners to simulate an invisible machine. That extends readable intent into the programming environment.
Where the fit has limits: His work challenges conventional text-first programming more radically than our Ruby/Rails approach. We are not calling him a Ruby advocate.
Put it to work: When explaining unfamiliar code, show a concrete input, intermediate state and result, rather than only the source text.
Read: Learnable Programming
Rich Hickey
Outside perspective; productive disagreement
Why the ideas fit: Separating structural simplicity from familiarity helps test whether a convenient abstraction actually reduces entanglement.
Where the fit has limits: Clojure’s functional design and explicit separation differ from Ruby’s mutable objects and Rails conventions. Borrow the question, not an entire language ideology.
Put it to work: List which concerns a new helper combines, then decide whether that coupling is necessary.
Read: Simple Made Easy — recorded talk
Simplicity and operational restraint
Dan McKinley
Selected operational influence
Why the ideas fit: Choosing technology by organizational cost includes operations and cognitive load. His account of Etsy’s shared stack illustrates benefits that may arrive long after the initial choice.
Where the fit has limits: Boring technology does not mean stagnant technology or a prohibition on justified additions and upgrades.
Put it to work: Compare the operational burden of a proposed service with extending the stack the team already understands.
Read: Choose Boring Technology
Martin Fowler
Selected architecture influence
Why the ideas fit: A monolith lets a team learn and refactor domain boundaries before distribution makes those changes expensive. That supports our measured approach to splitting services.
Where the fit has limits: Fowler labels his evidence anecdotal and tentative, discusses counterexamples and supports services when justified. This is not a never-microservices rule.
Put it to work: Identify the boundary and concrete scaling or ownership problem before extracting a service.
Read: Monolith First
Compatibility and safe change
Hyrum Wright
Selected compatibility influence
Why the ideas fit: Users can depend on observable behavior beyond an API’s written contract. Even performance can become an implicit dependency, so small changes need checks against actual consumers.
Where the fit has limits: This describes a constraint; it does not require preserving every bug forever. Deprecation and migration remain explicit decisions.
Put it to work: Before changing an interface, examine real callers and record observable behavior that must survive or be migrated.
Read: Hyrum’s Law
Kent Beck
Already credited in the project’s testing guidance
Why the ideas fit: His test desiderata include behavioral sensitivity, structure insensitivity, readability, isolation, determinism, speed and specificity. They help assess confidence rather than maximize assertion counts.
Where the fit has limits: Our site’s testing standards are its own synthesis, not Beck’s words or a checklist authored by him.
Put it to work: Review a test for the behavior it catches and for whether harmless refactoring breaks it.
Read: Test Desiderata · Our testing guide
Michael Feathers
Already credited in the project’s testing guidance
Why the ideas fit: Characterization tests capture what unfamiliar code currently does, making legacy behavior visible before a change.
Where the fit has limits: Observed behavior is not automatically the intended requirement. Preserving or correcting a bug remains a product decision.
Put it to work: Capture representative existing behavior, label surprises, and obtain a decision before changing expectations.
Read: Characterization Testing · Our testing guide
Hillel Wayne
Selected testing influence
Why the ideas fit: Metamorphic testing checks meaningful relationships between executions when exact answers are expensive to obtain. It adds useful tests for difficult oracles, including AI behavior.
Where the fit has limits: Wayne explains the technique, not invents it. Equal outputs can all be wrong, and a transformation must actually preserve the property being tested.
Put it to work: Pair a domain-valid transformation with known-answer examples; explain why the relation should hold.
Read: Metamorphic Testing
Databases and correctness
D. Richard Hipp and the SQLite team
Selected testing and implementation influence; shared credit
Why the ideas fit: SQLite documents independent harnesses, memory and I/O fault tests, crash testing, fuzzing and boundary cases. This gives substance to testing failure paths and using small native components behind a friendly API.
Where the fit has limits: Credit the team as well as Hipp. Its embedded architecture is not a blanket replacement for our PostgreSQL/RLS tenancy design, and its testing investment is unusually large.
Put it to work: Identify the relevant storage failure and test the recovery invariant, rather than copying a large test program without a risk model.
Read: How SQLite Is Tested · SQLite team
Kyle Kingsbury
Selected experimental influence
Why the ideas fit: Jepsen evaluates database guarantees through executable histories and explicitly defined anomalies. The PostgreSQL12.3 investigation is a concrete example of testing concurrency claims rather than relying on labels.
Where the fit has limits: The cited investigation is a historical version-specific finding, not a claim about current PostgreSQL. Testing cannot establish the absence of every bug.
Put it to work: State the invariant and failure model for a concurrent operation, then look for a history that violates it.
Read: Jepsen: PostgreSQL 12.3
Martin Kleppmann
Selected data-systems influence
Why the ideas fit: A lock used for efficiency has different stakes from one protecting correctness. His lease example explains how a paused client can resume with stale authority and why resource-enforced fencing matters.
Where the fit has limits: The article critiques particular assumptions and Redlock; it does not say Redis is unusable. Additional coordination must be justified by consequences.
Put it to work: Ask what happens if a worker resumes after losing its lease, and which component can reject its stale write.
Read: How to do distributed locking
Performance and operations
Brendan Gregg
Selected systems-performance influence
Why the ideas fit: The USE method asks about utilization, saturation and errors for each resource. It exposes missing measurements and complements our whole-request and host-level diagnosis.
Where the fit has limits: Resource bottleneck analysis complements workload and application-latency analysis. It does not replace Nate Berkopec’s Ruby/Rails guidance.
Put it to work: Create a resource checklist before selecting tools, and mark unavailable metrics as unanswered questions.
Read: The USE Method
Julia Evans
Selected debugging influence
Why the ideas fit: Her debugging guidance separates a specific guess from an experiment and encourages changing one thing at a time. This makes think-before-coding approachable and testable.
Where the fit has limits: The post credits other practitioners’ contributions. Its transferable method is not an endorsement of our language or stack.
Put it to work: Write a falsifiable guess, reproduce the symptom and change one relevant variable before interpreting the result.
Read: What does debugging a program look like?
John Allspaw
Selected engineering-practice influence
Why the ideas fit: Making tradeoffs explicit, anticipating operational consequences, seeking criticism and teaching colleagues connects technical judgment with constructive collaboration.
Where the fit has limits: This is experience-based guidance with credited influences, not a formal reliability guarantee or a Ruby-specific method.
Put it to work: Record known compromises in a change review and invite criticism before an incident makes them obvious.
Read: On Being A Senior Engineer
Security as a system property
Bruce Schneier
Selected security influence
Why the ideas fit: Security requires continuing prevention, detection and response rather than confidence that buying a product finishes the job. This connects revocation, secret handling and observability.
Where the fit has limits: The essay dates from2000. Its systems principle does not establish the details of today’s passkey or tenant-isolation implementation.
Put it to work: For each control, identify how failures are noticed and how access or damage is contained afterward.
Read: The Process of Security
Ross Anderson
Selected security-engineering influence
Why the ideas fit: His bank example joins bookkeeping invariants, authorization, monitoring and cryptography. It puts protection goals inside the surrounding human and operational system.
Where the fit has limits: This is a foundational threat-modeling source, not current implementation instructions or validation of a particular identity provider.
Put it to work: Name what must be protected, against whom, and which forbidden outcome the controls must prevent.
Read: Security Engineering, second edition, chapter1
AI engineering with evidence
Simon Willison
Selected AI-assisted engineering influence
Why the ideas fit: His coding workflow retains responsibility for understanding and checking execution. A deployment example reveals competing jobs behind an apparently successful outcome, then verifies the repair.
Where the fit has limits: His examples are often Python/JavaScript and tool-specific. Verification transfers; language choice and guaranteed AI reliability do not.
Put it to work: Inspect the actual resulting artifact and execution, not merely a tool’s success message or plausible generated code.
Read: Here’s how I use LLMs to help me write code
Chip Huyen
Selected evaluation and product influence
Why the ideas fit: Start from the user problem and a simple baseline, and validate the evaluation itself. Her examples question unnecessary AI/framework complexity and require AI judges to be checked against systematic human review.
Where the fit has limits: This is not opposition to AI or all abstractions. The examples are contextual lessons, not universal accuracy thresholds.
Put it to work: Compare a simpler baseline, define useful outcomes and check whether the evaluator agrees with careful human assessment.
Read: Common pitfalls when building generative AI applications