miruky

Posted on May 21

A Roundup of Engineering “Laws” from the English-Speaking World That Are Surprisingly Well-Known in Japan

#softwareengineering #career #programming #beginners

Introduction

Hi, I'm miruky.

Over a recent long weekend, I went out for drinks with an older friend from high school who works as a tech lead. We ended up talking about a project of his that had recently gone sideways, and at some point he said something like, "honestly, it was a textbook case of Brooks's Law." I had seen the term in a book before, but, embarrassingly enough, I could not quite recall what it actually meant.

This is not just about Brooks's Law. There is a long list of "the Law of X", "the X Principle", and "the X Effect" that every engineer seems to know. Other professions have their own proverbs and rules of thumb, but our field is unusually fond of inventing them. Probably some of it comes from English-speaking software culture, which has always enjoyed naming patterns.

A few off the top of my head: Brooks's Law, Conway's Law, Hyrum's Law, the Joshua Tree Principle, Stone Soup, the Boiling Frog, reinventing the wheel, yak shaving, and so on.

You can absolutely live without memorizing any of these, but I want to keep them within reach, both as a piece of engineering literacy and as a personal commitment to not repeat past mistakes. Some of them genuinely earn their keep during code review. So in this article, I am organizing the famous ones, each with a short definition and a note on when it actually matters in practice. Treat it as a personal cheatsheet.

A note on scope

This article prioritizes "do engineers actually use this in conversation?" and "does it show up in classic software engineering literature?" over strict academic accuracy. More obscure terms are intentionally omitted.

Laws
Other principles, strategies, and metaphors
How to use these terms

1. Laws

The star rating is my own rough sense of "how often this term actually comes up in engineering conversations and code reviews". It is not a strict ranking, just a feel for how often it shows up in technical writing, design discussions, and pull request reviews.

Stars	Meaning
★★★★★	5 stars. Heard often in conversation and code review
★★★★☆	4 stars. Common knowledge; comes up in design discussions and small talk
★★★☆☆	3 stars. Known by some, but less frequent in day-to-day talk
★★☆☆☆	2 stars. Appears in books and classics, less so in conversation
★☆☆☆☆	1 star. Fairly obscure; barely used in this article

First, the ones that are most commonly framed as "laws" in everyday software development.

1-1. Project and organization laws

Conway's Law ★★★★☆

The structure of a system tends to mirror the communication structure of the organization that built it.

If your auth team, payments team, and inventory team never talk to each other, you should not be surprised when that disconnect shows up in your API boundaries and your screen transitions. It looks like an architecture conversation, but a lot of the time it is really an org design conversation. The term shows up constantly in discussions of microservice boundaries, team splits, and responsibility lines.

Brooks's Law ★★★★☆

Adding people to a late software project can make it even later.

This is not the simple "do not add people, ever" rule it is sometimes flattened into. The point is that onboarding, alignment, reviews, merges, and decision coordination all grow with team size, so dropping new people into a burning project does not produce instant relief. It is the standard warning you hear before someone proposes "let's just throw more headcount at it."

Parkinson's Law ★★★★☆

Work expands so as to fill the time available for its completion.

If the deadline is a week, the work takes a week. If it is a month, it takes a month. Meetings behave the same way: a 30-minute agenda will happily absorb a 60-minute slot. This is the reason short deadlines, short review windows, and short meetings tend to be a good default. It is the same reason summer break homework somehow always gets finished only in the last few days, no matter how much time you started with.

Ninety-Ninety Rule ★★★☆☆

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.

This one is attributed to Tom Cargill at Bell Labs and is also quoted in Jon Bentley's Programming Pearls. The punchline is that the numbers sum to 180%. It is a tidy explanation of why "we're basically done, just a few tweaks left" is rarely trustworthy. The final edge cases, error handling, documentation, tests, and operational work tend to be heavier than anyone estimated.

Parkinson's Law of Triviality (Bikeshedding) ★★★☆☆

People tend to spend disproportionate time on small, easy-to-grasp problems rather than on the important and difficult ones.

The classic example is a committee that breezes past the design of a nuclear reactor but argues for hours about the color of the bike shed. In engineering, this shows up as architecture decisions getting waved through while a code review stalls on a variable name, a button color, or microscopic copy choices.

Peter Principle ★★★☆☆

People tend to be promoted until they reach a position where they are no longer effective, and then stay there.

Promoting your strongest developer to manager does not automatically produce your strongest manager. Being great at writing code and being great at hiring, evaluating, shaping teams, and negotiating budgets are different skills. Worth keeping in mind whenever you are thinking about engineering manager or tech lead role design.

Hofstadter's Law ★★☆☆☆

It always takes longer than you expect, even when you take into account Hofstadter's Law.

This one self-references on purpose. It lands during estimation, release planning, migrations, and legacy rewrites: "I padded the estimate this time, and even with that, we still ran out of time." A short, accurate description of how schedules actually behave.

1-2. Design and code laws

Postel's Law ★★★★☆

Be conservative in what you send, be liberal in what you accept. Also known as the Robustness Principle, from early TCP/IP RFCs.

In the early internet, this kind of tolerance helped systems interoperate. In modern web and security contexts, being too liberal in what you accept can mean fuzzy specs and exploitable corners, so "do not be too lenient on input" is also part of the conversation now. Input validation usually wants the opposite of pure tolerance.

Law of Demeter ★★★★☆

An object should only talk to its immediate neighbors. Also known as the Principle of Least Knowledge.

Long chains like user.getCompany().getAddress().getZip() quietly couple the caller to the internal structure of every object in the chain. The moment any of those internals change, the call site breaks. This law shows up in class design, domain modeling, and API design.

Law of Leaky Abstractions ★★★★☆

All non-trivial abstractions, to some degree, leak.

Using an ORM does not let you forget about SQL. Using the cloud does not let you forget about networking and IAM. Using React or Next.js does not free you from how the browser actually works. Abstractions are convenient, but the layer underneath never fully disappears.

Kernighan's Law ★★★★☆

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

A direct shot at one-liners, nested ternaries, gratuitous metaprogramming, and clever abstractions that read like riddles. Code is judged not by "can I write this?" but by "can I still read this in three months?" and "can I still fix this when it breaks at 2am?"

Atwood's Law ★★★★☆

Any application that can be written in JavaScript will eventually be written in JavaScript.

A neat summary of how web technologies have escaped the browser into the server, the desktop, mobile, the CLI, and IoT. If you have spent any time in the Electron / Node.js / React Native part of the world, this one writes itself.

Hyrum's Law ★★★☆☆

With a sufficient number of users of an API, all observable behaviors of your system will be depended on by somebody.

Anyone who has ever shipped a public API has lived through this. The accidental key order in a response, an error message that happens to be stable, a request that happens to complete in a predictable amount of time: even when none of that is part of the documented contract, somebody will end up depending on it. Anything visible can become a contract.

Linus's Law ★★★☆☆

Given enough eyeballs, all bugs are shallow. The phrase was coined by Eric S. Raymond in The Cathedral and the Bazaar and named in tribute to Linus Torvalds's development model, not by Linus himself.

Roughly: with enough people looking at the code, bugs get found and root-caused faster. Useful when explaining the value of code review, open source, audits, and bug bounties. The catch is that headcount alone does not buy safety; reviewers need relevant expertise, code needs to be reviewable, and you need tests and reproducible builds to back any of it up.

Zawinski's Law ★★☆☆☆

Every program attempts to expand until it can read mail.

The serious version: useful tools accumulate features until they have quietly become full platforms. The tiny task tracker grows a chat tab, then a calendar, then mail, then AI, then workflows.

Sturgeon's Law ★★☆☆☆

Ninety percent of everything is crap.

Bluntly useful when evaluating libraries, sample code, blog posts, OSS projects, or AI-generated code. The job is not to admire everything that exists, but to develop an eye for the worthwhile 10%.

1-3. Performance and scale laws

Moore's Law ★★★★☆

Transistor density on integrated circuits has doubled at a roughly constant cadence.

Originally a prediction about component count on a chip, later stretched into a broader story about ever-increasing compute. Physical limits and manufacturing costs have made the simple version harder to maintain, so the current reality is more nuanced than the classic framing.

Amdahl's Law ★★★★☆

The speedup you get from parallelizing a program is limited by the part that cannot be parallelized.

A cold shower for "just add more servers and it will be faster." If the bottleneck is a DB lock, a single queue, an external API, or some synchronous step in the middle, more workers will not save you past a certain point. It is the standard mental model when discussing multithreading, distributed processing, and host-side overhead in GPU workloads.

Wirth's Law ★★★☆☆

Software gets slower faster than hardware gets faster.

Hardware keeps improving, and yet perceived speed often does not, thanks to ballooning dependencies, more abstraction layers, Electron-everything, and an endless stream of new features. Comes up whenever someone is talking about performance work or trimming bloat.

Metcalfe's Law ★★★☆☆

The value of a network grows roughly with the square of the number of its users.

With n participants, the number of possible pairs is n(n-1)/2, which scales close to n² for large n. That is the basis for the "value proportional to the square of users" framing. Common in explanations of social networks, marketplaces, telecom networks, and developer communities.

Gustafson's Law ★★☆☆☆

If you can grow the problem with the machine, parallelization pays off more than Amdahl suggests.

Amdahl's Law asks "how fast can I make a fixed workload?". Gustafson's Law asks "now that I have more compute, how much bigger a problem can I tackle?". You see it most often in HPC, batch processing, and large-scale data work.

1-4. Metrics and decision laws

Pareto Principle (80/20 Rule) ★★★★★

A small share of causes is responsible for a large share of the outcomes. Famous well outside engineering.

Most incidents tend to cluster in a few features. Most support tickets tend to cluster on a few screens. Most revenue tends to come from a few customers. Handy when prioritizing critical bugs, key users, and recurring support themes.

Murphy's Law ★★★★★

The compact version: anything that can go wrong, will go wrong.

In practice, this is not "expect doom" but "stop assuming nothing will fail, and start designing for what happens when it does". It is the friendly companion of failure design, retries, monitoring, backups, idempotency, and fail-safe defaults. The classic illustration is the slice of buttered toast that, when knocked off the table, lands butter-side down.

Goodhart's Law ★★★★☆

When a measure becomes a target, it ceases to be a good measure. The pithy form is usually credited to Marilyn Strathern's restatement.

Make test coverage a target and you get tests that exist mostly to lift the number. Make velocity a performance metric and ticket splitting becomes a game. Make incident count a goal and small incidents stop getting reported. Metrics are useful as signals, but they get corrupted the moment they become objectives in themselves.

Gall's Law ★★★☆☆

A complex system that works is invariably found to have evolved from a simple system that worked.

Starting from a giant ideal architecture rarely beats starting from something small that works and then growing it. The principle bites hard on new products, big replatform projects, and platform overhauls.

Campbell's Law ★★☆☆☆

The more any quantitative indicator is used for decision-making, the more it tends to distort and corrupt the processes it is intended to monitor.

A close cousin of Goodhart's Law, more often cited in evaluation, education, and policy contexts. In engineering organizations, tying compensation directly to PR count, commit count, story points, or review count tends to produce predictable distortion.

2. Other principles, strategies, and metaphors

This second group is not strictly "laws", but it includes principles, strategies, indicators, metaphors, and phrases from classic books that show up constantly in engineering conversations.

2-1. Design principles

DRY ★★★★★

I have been called out on this in real code review. Short for Don't Repeat Yourself: do not duplicate the same piece of knowledge in multiple places.

It is often misread as "do not write the same line twice." The thing you really must not duplicate is knowledge: business rules, constants, schemas, specifications. Forcing two coincidentally similar chunks of code into a single shared abstraction tends to backfire when the two reasons for change start diverging. The Pragmatic Programmer is the canonical reference.

KISS ★★★★★

Short for Keep It Simple, Stupid: prefer the simplest design that solves the problem.

This shows up in design, API shape, runbooks, and team rules. Choose a structure you can read, explain, and recover from when it breaks, over one that merely looks clever. Simple really is best, more often than not.

YAGNI ★★★★★

Short for You Aren't Gonna Need It: do not build features you do not need yet. An Extreme Programming staple.

This is not "ignore the future." It is "do not pay today's cost for tomorrow's hypothetical." A surprising amount of code written "just in case" never gets used in the form you imagined.

SOLID ★★★★★

A mnemonic for five object-oriented design principles.

Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. SOLID gets some legitimate criticism in modern contexts, but as a shared vocabulary for talking about dependencies, reasons for change, and responsibility boundaries, it is still very much in use.

Single Responsibility Principle ★★★★★

I hear this one a lot. A module or a class should have only one reason to change.

It does not mean "one method per class." If changes to your user view, your billing rules, and your DB storage format all flow through the same class, that class is probably doing too much.

Separation of Concerns ★★★★★

Do not blend unrelated concerns into the same place.

When UI, domain logic, DB access, auth, logging, notifications, and external API calls all live tangled together, every change becomes scary. This is the idea sitting under layered architecture, clean architecture, and MVC.

Principle of Least Privilege ★★★★★

Genuinely essential. Grant only the minimum privileges required.

Applies broadly: IAM, DB permissions, CI/CD, GitHub Actions, AI agents, MCP tools, admin dashboards, the lot. The default is not "open it up until people stop complaining", but "figure out the smallest scope that works and hand out exactly that."

Open-Closed Principle ★★★★☆

Software entities should be open for extension, but closed for modification.

The goal is to add a new payment method or a new notification target without rewriting half the existing code. Pushed too far it produces an abstraction graveyard, so it needs to live in tension with YAGNI.

Principle of Least Astonishment ★★★★☆

Behave in a way that does not surprise the user.

Applies to function names, API responses, UI, default values, and CLI flags. A function called deleteUser() that actually performs a hard delete when the rest of the system uses soft deletes, or a get endpoint that mutates the database, will surprise people. Surprise is a bug.

Unix Philosophy ★★★★☆

Build small tools, make them compose well.

The familiar slogans, "do one thing and do it well", "communicate via text streams", "compose small tools", come from Unix culture. The influence is clearly visible in CLIs, pipes, microservices, and modern developer tooling.

WET ★★☆☆☆

The anti-DRY: variously expanded as Write Everything Twice, Write Every Time, or We Enjoy Typing. It describes a bad state.

You end up with the same logic, the same rule, or the same configuration scattered across the codebase. When the spec changes, you fix one copy and forget the other; docs drift away from the code; tests still assert the old behavior. The DRY / WET pairing is one of the more fun bits of vocabulary in the field.

ETC (Easier to Change) ★★☆☆☆

A guiding value from The Pragmatic Programmer (20th anniversary edition): make code easier to change.

The book explicitly frames ETC as a value, not a rule. DRY, KISS, YAGNI, and Separation of Concerns can all be read as instances of "will this make the next change easier or harder?". When you are stuck between two designs, asking that question often unblocks the decision.

2-2. Methods and metaphors from classic books

Prototype ★★★★★

Code you write specifically to learn, with the expectation of throwing it away.

Useful for de-risking an unfamiliar technology, a UI direction, a library, or a performance profile. The danger is conflating "things I am going to grow into production code" with "things I am going to throw away." Code written to be thrown away has a nasty habit of being shipped instead.

Reinventing the Wheel ★★★★★

You hear this constantly. Rebuilding something that already exists, for no good reason.

Standard examples include writing your own framework or, worse, your own crypto without checking the existing ecosystem first. A clear caveat: rebuilding something for learning purposes, or to satisfy a constraint that no off-the-shelf option supports, can be valuable. The problem is ignoring existing knowledge and repeating other people's mistakes.

Boiling Frog ★★★★☆

When conditions worsen slowly, people tend to miss the danger. The Pragmatic Programmer introduces it alongside Stone Soup.

The story (a frog in slowly heating water failing to notice the danger) is used as a metaphor for slow decay. Builds get one minute slower. Tests get slightly flakier. A few more type errors get ignored. Each step is small enough to overlook, but the cumulative effect is a much slower team. This is the shape of technical debt. The biological version is not actually accurate; treat it strictly as a software-engineering metaphor.

Broken Windows Theory ★★★★☆

If you tolerate small messes, larger messes follow. Famous outside engineering as well.

In code: failing tests, sloppy naming, abandoned TODOs, unformatted files, perpetually red CI. Letting these sit broadcasts the message "this repo is fine to treat carelessly," which then attracts more carelessness.

Rubber Duck Debugging ★★★★☆

Explain the problem out loud and you often spot the bug yourself.

The audience does not have to be human. A rubber duck on your desk works fine. Walking through the code line by line forces you to confront the gaps in your own understanding, which makes it useful as a pre-review self-check too.

No Silver Bullet ★★★★☆

There is no single technology that can deliver a tenfold productivity improvement to software development on its own. Frederick Brooks's famous argument.

New languages, frameworks, clouds, and AI tools do not erase the essential difficulties of understanding requirements, managing complexity, accommodating change, and communicating with people. A handy phrase for tempering hype around new technology. ("Silver bullet" here is the folkloric weapon that kills monsters in one shot.)

Yak Shaving ★★★★☆

Doing a chain of prerequisite tasks before you can get to the thing you actually wanted to do.

"I just wanted to fix this small bug, but to run the tests I had to upgrade Node, and to upgrade Node I had to fix CI, and to fix CI I had to revisit permissions, and now I have no idea what I was originally doing." Very common during environment setup and dependency upgrades.

Stone Soup ★★★☆☆

A metaphor for kickstarting a small change that ends up pulling other people in.

The folk tale: a traveler offers to make a soup from a stone, sets up a pot, and asks each villager to contribute one small ingredient. By the end, there is a real soup.

In a codebase, the equivalent is something like: "Let's refactor the whole module" goes nowhere, but a small, concrete improvement PR ships. Someone else sees it and adds tests. Someone else adds docs. Before long, an improvement effort exists.

Tracer Bullets ★★★☆☆

Cut a thin slice all the way through the system, end to end, as your first real implementation.

The metaphor is borrowed from tracer rounds in ballistics: rounds that glow in flight so you can correct your aim in real time.

This is not the same as a throwaway prototype. The tracer-bullet slice is meant to be real, just narrow: UI, API, DB, deploy, and monitoring, all wired up at the smallest viable scope, then widened over time. It overlaps with the idea of a "walking skeleton."

The difference from a prototype is intent. A prototype is meant to be thrown away. A tracer-bullet slice is meant to be kept and grown. Both are tools for fast feedback, but they live different lives.

2-3. Cognition and learning metaphors

Joshua Tree Principle ★★★★★

This one resonates with me. Once you learn the name of a thing, you start noticing it everywhere.

Not so much an academic law as a metaphor that gets phrased as the Joshua Tree principle or Joshua Tree epiphany. Learn the name "Hyrum's Law", and you start spotting "uh-oh, somebody is going to depend on this exact behavior" during API review. Design patterns, anti-patterns, incident patterns, and cognitive biases all become much easier to spot once you have a label for them.

Dunning-Kruger Effect ★★★★☆

People with low ability in a domain tend to overestimate their ability.

The pop version is "beginners are overconfident", but the real claim is subtler: the metacognitive skill needed to notice your own mistakes is one of the things you are missing in the first place. There is a clear parallel with over-trusting AI-generated code. In any unfamiliar area, hold back on certainty and insist on verification and review.

Confirmation Bias ★★★★☆

The tendency to seek and weigh information that fits the hypothesis you already hold.

In incident response, deciding "this is a DB problem" makes you read every log through DB-colored glasses. The same thing happens during performance tuning and code review. Forming a hypothesis is fine; the discipline is to also look for the evidence that would refute it.

Occam's Razor ★★★★☆

Among competing explanations of equal predictive power, prefer the one with fewer assumptions.

Named after the 14th-century philosopher and theologian William of Ockham. The original "do not multiply entities beyond necessity" is often described as shaving away unnecessary assumptions with a razor.

In incident response, before reaching for an exotic distributed-systems bug, check the boring options first: a misconfiguration, a missing env var, a forgotten deploy, an unusual input, a time-zone bug. The simple explanation is not always right, but it is a strong opening hypothesis.

Chesterton's Fence ★★★★☆

Do not remove a fence you do not understand the purpose of, until you understand its purpose.

The image, from G.K. Chesterton, is of someone walking down a road and finding a fence that seems pointless. The first move is not "tear it down because it serves no use", but "find out why it was built in the first place."

In legacy code, when you find a strange if branch or a baffling config switch, it is tempting to delete it on sight. But it may be the residue of a real production incident, a customer-specific requirement, or a regression workaround. Check logs, issues, commit history, and other engineers' memory before removing it.

Survivorship Bias ★★★☆☆

Drawing conclusions only from the cases that survived to be visible.

Studying only successful startups, popular OSS, and viral blog posts will quietly convince you that "doing X is the path to success." What is missing from view is the much larger pile of efforts that did the same thing and failed. Worth holding in mind during tech selection and career conversations.

Baader-Meinhof Phenomenon (Frequency Illusion) ★★☆☆☆

The feeling that a word you just learned is suddenly appearing everywhere.

Right after picking up a new technical term, you start spotting it in your feed, in articles, in meetings. The world did not change, your attention did.

2-4. Architecture and distributed systems staples

CAP Theorem ★★★★★

In a distributed system, you cannot simultaneously and perfectly satisfy consistency, availability, and partition tolerance.

The "pick two out of three" phrasing is the famous one, but in practice it is more useful to think of CAP as describing a design choice that becomes visible when a network partition actually happens: under partition, do you preserve consistency or availability?

Idempotence ★★★★★

A property where performing the same operation multiple times has the same effect as performing it once.

More precisely: applying the operation once or many times results in the same intended effect on the server's state, even if the response payload varies. Networks fail. Retries happen. So a payment request, a webhook handler, or any critical operation needs to be safe to receive more than once without double-charging or duplicating effects. Crucial in payments, job processing, and API design.

Fail-safe ★★★★★

When something fails, fall toward the safer outcome.

Authorization errors fall toward "deny", not "allow". An ambiguous payment state falls toward "hold", not "double-charge". A control system falls toward "stop", not "uncontrolled motion". Foundational in security and safety design.

Foolproof ★★★★★

Design so that human error is unlikely to cause damage. The Japanese-coined equivalent is poka-yoke from manufacturing.

Add a confirmation step to delete buttons. Require typing the environment name to run destructive commands in production. Disable dangerous CLI flags by default. Make inputs into select boxes instead of free text. Leverage the system's design, not the user's vigilance, to prevent mistakes.

Eventual Consistency ★★★★☆

Replicas do not agree immediately, but they will agree given enough time.

Common in NoSQL stores, caches, event-driven systems, and async pipelines. A read immediately after a write may see the old value; given some time, all replicas converge.

Fail-fast ★★★★☆

If something is wrong, stop early rather than carrying the problem forward.

Missing config, malformed input, a dependency that is unreachable: better to fail right at the boundary than to propagate the problem into later stages of the system. Shows up in input validation, config checks, CI, and startup self-checks.

Backpressure ★★★☆☆

When a consumer cannot keep up, slow the producer down.

You see this with queues, streams, rate-limited APIs, and log pipelines. If the consumer is stuck and the producer keeps pushing, memory grows, latency grows, and eventually something crashes. Backpressure is the discipline of flow control.

Graceful Degradation ★★★☆☆

When part of the system breaks, keep as much of the rest working as possible.

If an external API goes down, keep the core flows alive. If recommendations are unavailable, still render the product list. If image processing is slow, still show the text. This is the language of degraded modes and resilience.

2-5. Organization and development strategy

Bus Factor ★★★★☆

A peculiarly engineering metric: the number of people who would need to disappear for the project to be in trouble.

A bus factor of 1 means a single resignation, transfer, or extended absence can break the project. The term is shorthand for risk from siloed knowledge, weak documentation, and weak review coverage. You raise the bus factor with code review, pair work, runbooks, and rotation.

Inverse Conway Maneuver ★★★☆☆

Use Conway's Law in reverse: shape the organization to fit the architecture you want.

"We want these service boundaries, so let's organize teams along those same boundaries." Sits naturally next to ideas like Team Topologies, platform teams, stream-aligned teams, and bounded contexts.

3. How to use these terms

The vocabulary above is useful, but it is not magic.

3-1. Do not let the name end the discussion

"That's just Brooks's Law." "That's YAGNI." "That's Conway." If the conversation ends there, you are casting spells instead of thinking.

The trick is to follow up with something concrete.

[Bad]
"That's YAGNI."

[Good]
"Do we have a concrete requirement for that extension point this quarter?"

[Bad]
"Brooks's Law, so no."

[Good]
"If we add people now, the onboarding and review overhead will probably cost us at least two weeks before it pays back."

Names are shortcuts. Use them to start a deeper conversation, not to skip one.

3-2. Translate the classics into your context

Books like The Pragmatic Programmer, The Mythical Man-Month, The Unix Philosophy, and the rest of the classic software engineering canon still hold up. Plenty of what they describe is directly useful today.

But pulling those terms straight into modern web development, cloud, AI agents, or distributed systems sometimes needs translation.

Stone Soup, today: ship a small, concrete improvement PR and let it pull others in.
Boiling frog, today: ignore the slow drift of CI getting slower and type safety getting looser.
Reinventing the wheel, today: building it yourself without checking the existing libraries. Still valuable as a learning exercise; harmful as a default reflex.
Leaky abstractions, today: even with cloud and AI tooling, you cannot fully forget the layer below.

The point of the classics is not to memorize them. It is to give the awkward feelings you already have in real projects a name you can point at.

And please, do not become the person who weaponizes English jargon to win arguments.

Wrap-up

Thanks for reading this far.

The famous engineering laws and metaphors are not just trivia. They give short names to why estimates miss, why org structure shows up in the code, why public APIs ossify in odd places, why metrics go bad, and why technical debt grows quietly. Once you have the name, you can recall the whole pattern in a second.

If there is one thing I would like you to take away from this article, it is that once you know the name of a thing, you start spotting it in the wild. That is the Joshua Tree Principle in action.

See you in the next one.

About this article

This article is the English adaptation of a Japanese post I originally wrote on Qiita, a developer community popular in Japan.

【エンジニアの教養】なぜかエンジニア界隈で有名な◯◯の法則的なやつをまとめてみた #Security - Qiita

前置きこんばんは、mirukyです。この間のGW中に、高校時代の先輩（テックリード）と飲みに行きました。そのとき先輩が経験した炎上プロジェクトの話になり、先輩が「ブルックスの法則ってあるじゃん。まさしくあれになってさ」みたいなことを言っていたのですが、本で見たこと...