hacker-laws: A Reference List of Engineering Laws, Principles and Patterns

What hacker-laws actually is, and who it is for

The repository is a Markdown document, not a tool. Its description calls it "Laws, Theories, Principles and Patterns for developers and technologists", and the introduction frames it as "a reference and overview of some of the most common ones". That framing matters more than it first appears. Most of the entries are not laws in any enforceable sense. The introduction says laws "can be opinions on inevitabilities in the world of software engineering, or wry observations on unavoidable realities", which is an honest description of a list that puts Amdahl's Law next to the 90-90 Rule and Wheaton's Law.

The audience is narrow and identifiable: engineers who need a name and a short explanation for something they already suspect, usually mid-discussion. If a colleague says a rewrite will take longer than the estimate, Hofstadter's Law gives that intuition a label. If an interface change breaks callers who depended on undocumented behaviour, Hyrum's Law gives it a label. The repository is for that moment, when a shared vocabulary shortens an argument.

It is not a curriculum. The README points to a Reading List and Online Resources section for people who want depth, and the entries themselves link out to Wikipedia and other primary sources. Treat the repository as an index with commentary, and the external links as the actual reading.

How the repository is organised and how the content flows

The top level of the repository holds README.md, LICENSE, an assets directory, an images directory, a .github directory and a translations directory. The README opens with a table of contents generated by vim-markdown-toc, then splits the content into three main groups: Laws, Principles, and a Reading List, followed by Online Resources, a Podcast section and Contributors.

Each entry follows a consistent shape. A heading names the law, often with an alternate name in parentheses, such as "Hick's Law (Hick-Hyman Law)" or "Hyrum's Law (The Law of Implicit Interfaces)". A link points to a Wikipedia page or another external source. A short explanation follows, and where the author has examples, they appear as a quote or a bulleted list. Many entries close with a See Also block that cross-references related laws, which is the most useful structural feature in the document. The 90-9-1 Principle entry, for example, ends by pointing to the Pareto Principle.

The rendering path is similarly plain. The README lists a homepage at hackerlaws.dev, and the description in the repository metadata points to the same site. The repository itself is HTML according to the language metadata, which reflects the generated site output rather than the source text. The source of truth is the Markdown on the main branch.

The translations directory holds community translations, and the README links to several of them, including pt-BR, fr, it-IT, lv, es-ES, tr, id, jp, pl and vi. Some translations live in this repository and some, notably the Chinese and Korean versions, live in separate repositories maintained by other people. That split is worth knowing before you assume every translation tracks the current main branch.

Installing nothing: reading hacker-laws locally and on the web

There is no package to install, no CLI and no server. The project is a document plus a website, so the closest thing to installation is cloning the repository and reading the Markdown, or opening the hosted site. The README gives the site address directly.

To work with the text offline, clone the repository as you would any other:

git clone https://github.com/dwmkerr/hacker-laws.git
cd hacker-laws

After the clone finishes you have README.md at the repository root. Open it in any Markdown viewer or editor. The table of contents at the top uses anchor links, so a viewer that renders GitHub-flavoured Markdown will let you jump between entries without scrolling.

If you only need one entry, the GitHub blob view on the main branch is enough, and the hosted site at hackerlaws.dev renders the same content for reading in a browser. The README also links a podcast episode, "The Changelog - Laws for Hackers to Live By", for people who prefer listening to a discussion of the material.

Contributions go through pull requests. The introduction says "Please share and submit PRs!" and points to a contributing guidelines file under .github for the details. The README notes that contributions will be acknowledged "where reasonably practical", which is a softer commitment than many projects make, and worth reading as such.

Where the reference format breaks down

The most consequential limitation is stated by the project itself. The introduction carries a warning that the repo "contains an explanation of some laws, principles and patterns, but does not advocate for any of them", adding that whether they should be applied "will always be a matter of debate, and greatly dependent on what you are working on". Anyone who wants a rulebook will be disappointed, and anyone who quotes an entry as settled guidance is misusing the source.

The entries also vary in weight. Some are empirical claims with references, such as the 90-9-1 Principle entry, which cites a 2014 study of digital health social networks. Others are jokes with a point, like the 90-90 Rule and Wheaton's Law. Presenting both kinds in one alphabetical list flattens that distinction. A reader skimming the table of contents cannot tell which entries have evidence behind them and which are folklore with a Wikipedia page.

Coverage is another boundary. The list is a selection, not an exhaustive catalogue, and the introduction calls it an overview "of some of the most common ones". If your field is not represented, the repository will not help. There is also no versioning of the ideas themselves: entries can be edited, and the README does not document a changelog for individual entries, so a citation to a specific claim should include the date you read it.

Finally, this is the wrong tool for anyone who needs depth on a single topic. One paragraph and a Wikipedia link is the format. If you need to understand the CAP Theorem well enough to make a storage decision, the entry is a starting point that tells you the topic exists, nothing more.

How it compares with a wiki and with a book

The closest alternative in kind is Wikipedia itself, and the comparison is not flattering to either side. Wikipedia has broader coverage, editorial review and citation requirements, and it is where most of the hacker-laws entries send you anyway. What the repository offers instead is curation and adjacency: the entries are chosen for relevance to software work, and the See Also links connect ideas that Wikipedia treats as separate articles. Conway's Law and the Two Pizza Rule sit near each other here in a way they would not on a general encyclopedia.

A second alternative is a book on software design, and the README points to one by the same author, Effective Shell, though that covers a different subject. The difference in approach is depth against breadth. A book argues a position across chapters and expects you to follow the reasoning. hacker-laws presents positions without arguing them, which is why it is fast to consult and useless as a guide to what to do.

A third option is an internal engineering handbook. That is the only format that can encode your team's decisions rather than general observations. If your goal is to settle how your team builds software, hacker-laws can supply the vocabulary for the handbook, but the handbook still has to be written, and the repository's own warning about not advocating for anything is the reason it cannot be that handbook.

Licence, maintenance and the cost of keeping up

The repository is licensed CC-BY-SA-4.0. That is a content licence, not a software licence, and the share-alike term means derivative works must carry the same licence. For a team quoting a definition in an internal document, that is unlikely to matter. For anyone republishing entries, translating them, or folding them into a product, the terms are worth reading in the LICENSE file at the repository root before you copy text. This is a description of the licence, not legal advice.

The last push to the repository was on 2026-09-10, and the most recent release listed is v0.6.0 from 2026-05-19, following v0.5.0 in February 2026 and v0.4.0 in December 2025. Those dates describe a project that is still receiving changes, though the release cadence is modest and the content is stable by nature: definitions of established laws do not need frequent revision. The maintenance cost for a user is close to zero, since there is nothing to upgrade. The cost that does exist is editorial: entries can change or be reworded, so if you cite one in a document that lives for years, pin the citation to a commit or a release tag rather than to the main branch.

The translations carry a different maintenance risk. Some are maintained inside this repository and some live in separate repositories under other accounts, and the README does not state that any translation tracks main. If you need a translation for a team, check the last commit date on that specific translation before depending on it.

Editorial conclusion

Adopt hacker-laws if you want a citable, linkable reference for the named laws your team already argues about, and if the CC-BY-SA-4.0 share-alike terms suit how you plan to reuse it. Do not adopt it as a style guide, a process document, or a source of settled answers: the README says the repo does not advocate for any of the entries, and the entries mix laws with wry observations. Before you rely on a specific entry, open the file on the main branch and read the See Also links, because the repository is an overview and the primary sources carry the detail. Check the LICENSE file in the repository root before republishing any part of the text.

Frequently asked questions

Official sources

1. dwmkerr/hacker-laws on GitHub
2. License: CC-BY-SA-4.0
3. Project website
4. README
5. Releases